Identity Security Fundamentals

Identity security encompasses the frameworks, controls, and technical mechanisms organizations deploy to verify who or what is requesting access to systems, data, and infrastructure — and to enforce appropriate boundaries on that access. This page covers the definition and operational scope of identity security, the mechanisms by which it functions, the scenarios where it is most critically tested, and the decision thresholds that distinguish one control category from another. The subject sits at the intersection of federal regulatory requirements, international standards, and operational risk management across enterprise and public-sector environments.

Definition and scope

Identity security is the discipline concerned with ensuring that only authenticated, authorized, and appropriately governed principals — users, devices, service accounts, and non-human identities — can access protected resources. It is distinct from network perimeter security, which focuses on traffic boundaries, and from endpoint security, which focuses on device integrity, though all three domains intersect in modern zero trust architectures.

The scope of identity security spans four functional domains recognized by NIST Special Publication 800-63, the federal digital identity guidelines maintained by the National Institute of Standards and Technology:

1. Identity proofing — Establishing that a claimed identity corresponds to a real-world subject at a defined assurance level (IAL1, IAL2, or IAL3 under NIST SP 800-63A).
2. Authentication — Verifying that a principal presenting credentials is the same entity whose identity was proofed (AAL1, AAL2, AAL3 under NIST SP 800-63B).
3. Federation — Enabling identity assertions to cross organizational or system boundaries using standards such as SAML 2.0 and OpenID Connect (FAL1–FAL3 under NIST SP 800-63C).
4. Authorization and governance — Controlling what authenticated principals are permitted to do, and managing the lifecycle of those permissions.

The Federal Information Security Modernization Act (44 U.S.C. § 3551 et seq.) places identity assurance obligations on federal agencies, and the Cybersecurity and Infrastructure Security Agency (CISA) reinforces these through binding operational directives including BOD 22-02, which mandates remediation of exploited vulnerabilities that frequently enable credential compromise. The identity security providers maintained within this network map service providers and frameworks against these regulatory anchors.

How it works

Identity security operates through a layered control chain. A principal requesting access passes through authentication, then authorization, with each layer applying a defined policy engine.

Authentication layer: The principal presents one or more factors — knowledge (password or PIN), possession (hardware token, smart card, mobile authenticator), or inherence (biometric). Multi-factor authentication (MFA) combines at least 2 of these factor types. NIST SP 800-63B classifies authenticators by assurance level: a single-factor software credential meets AAL1; a phishing-resistant hardware authenticator such as a FIDO2 passkey is required for AAL3.

Authorization layer: Once authenticated, the principal's permissions are evaluated against a policy. Three dominant models structure this evaluation:

• Role-Based Access Control (RBAC) — Permissions are assigned to roles; principals inherit permissions through role membership. Defined under NIST SP 800-207 as a foundational model.
• Attribute-Based Access Control (ABAC) — Permissions are evaluated dynamically based on subject attributes, resource attributes, and environmental conditions at access time.
• Policy-Based Access Control (PBAC) — A superset of ABAC in which centralized policy engines evaluate rules across multiple attribute sources simultaneously.

Governance layer: Identity governance and administration (IGA) functions manage the lifecycle of accounts and entitlements — provisioning, periodic access reviews (sometimes called access certifications), and deprovisioning. The page describes how this provider network organizes these practice categories.

Common scenarios

Identity security controls are most critically tested in four recurring operational scenarios:

Credential compromise: An attacker obtains valid credentials through phishing, credential stuffing, or data breach exposure. Controls that limit damage include MFA enforcement, anomalous login detection, and privileged access management (PAM) solutions that vault and rotate credentials. The IBM Cost of a Data Breach Report 2023 identified stolen or compromised credentials as the most common initial attack vector, involved in 15% of breaches (IBM Security, 2023).

Privilege escalation: A legitimately authenticated user gains access rights beyond their authorized scope — either through misconfigured role assignments, unrevoked legacy permissions, or exploitation of software vulnerabilities. Least-privilege enforcement and just-in-time (JIT) access provisioning are the primary countermeasures.

Third-party and non-human identity sprawl: Service accounts, API keys, OAuth tokens, and machine identities often accumulate at rates exceeding human identity counts within large organizations. These identities frequently lack the governance controls applied to human accounts. CISA's Secure by Design guidance addresses non-human credential management as an architectural priority.

Federated identity abuse: When identity assertions cross trust boundaries — between cloud providers, between a vendor and a customer organization, or between an agency and a contractor — federation misconfigurations can allow forged or replayed assertions to bypass authentication. The SolarWinds intrusion, publicly attributed by the US government in 2021, exploited federated trust relationships to move laterally across cloud environments.

For a structured view of practitioners and services addressing these scenarios, see the how to use this identity security resource page.

Decision boundaries

Identity security decisions pivot on three classification thresholds that distinguish appropriate control levels:

Assurance level vs. risk tolerance: Not all access decisions warrant the same authentication strength. NIST SP 800-63 defines three Identity Assurance Levels (IAL) and three Authenticator Assurance Levels (AAL). Accessing a low-sensitivity public application may require only AAL1; accessing federal agency systems holding personally identifiable information typically requires AAL2 at minimum, with AAL3 mandated for privileged administrative access under OMB Memorandum M-22-09, the federal zero trust strategy.

IAM vs. PAM: Identity and Access Management (IAM) governs the broad population of user and service identities across an organization. Privileged Access Management (PAM) is a specialized subset focused on accounts with elevated permissions — domain administrators, database superusers, and cloud infrastructure roles. PAM solutions apply additional controls including session recording, credential vaulting, and time-limited access grants that are not standard in general IAM platforms.

Authentication vs. authorization failures: These two failure modes require different remediation paths. An authentication failure — a compromised password or token — is addressed through credential rotation, MFA enforcement, and re-proofing. An authorization failure — an account accessing resources it should not — requires access review, role model correction, and often IGA process reform. Conflating the two leads to control gaps where one layer is hardened while the other remains exposed.

The boundary between identity security as an internal IT function and identity security as a compliance obligation is defined by statute and sector-specific regulation: the Health Insurance Portability and Accountability Act (45 C.F.R. Part 164) for healthcare, the Gramm-Leach-Bliley Act Safeguards Rule (16 C.F.R. Part 314) for financial services, and FedRAMP authorization requirements for cloud services used by federal agencies.