CompTIA Security+ SY0-801 Identity and Access Management: SSO, MFA, Access Control Models and Passkeys

Provisioning creates a person's accounts and grants the access their job needs; deprovisioning disables or removes that access when they leave. Between the two sits every job change, and each one should both add the new role's permissions and take away the old ones. Identity and access management (IAM) is the discipline of running that lifecycle so the right people have the right access, for the right reasons, for only as long as they need it.

Joiners, movers and leavers

• Joiners are provisioned after their identity has been proofed (next section), usually from a role template so access is consistent and approved.
• Movers need their old access removed as well as new access added. Skipping the removal step is the most common source of excess access.
• Leavers must lose access promptly, ideally triggered automatically by the HR system on the last day. When a former employee's credentials still work after they have gone, the root cause lies in the lifecycle process, not in how sign-in is checked.

Deprovisioning has to reach every application

Disabling the directory account blocks new single sign-on (SSO) sign-ins, but it does not automatically end everything. Many SaaS and internal applications keep their own local users, issue their own long-lived API tokens and personal access tokens, and hold sessions that outlive the directory change. Complete deprovisioning revokes access inside each application as well, which is what automated provisioning standards such as SCIM (System for Cross-domain Identity Management) are for: the identity provider tells each connected application to create, update, deactivate or remove users. Where the application supports it, deactivation also revokes the user's tokens and sessions; where it does not, they have to be revoked in the application itself. The general principle: a control applied only at the SSO front door cannot reach a credential that never passes through it.

Permission assignments and privilege creep

Every permission assignment has implications beyond the task it was granted for. When people change roles and keep their old rights, access piles up; this is privilege creep (also called permission or access creep). Its danger is the toxic combination: an engineer who can both change code and approve its release to production, or a clerk who can both raise and approve a purchase order, breaks separation of duties even though every individual right was legitimately granted. The defining feature of creep is that every right was granted legitimately and simply never taken away. That separates it from privilege escalation, where someone obtains rights that were never granted, by exploiting a flaw or misconfiguration, and from orphaned accounts, which have no current owner at all (typically a leaver's account that was never disabled).

Least privilege, group- or role-based assignment instead of one-off grants, removal on every move, and regular access reviews are the controls that keep assignments honest.

Identity proofing verifies that a person really is who they claim to be before an organization issues credentials to them, or resets credentials they have lost. It comes before authentication: authentication checks a credential the person already holds, while proofing establishes who should receive that credential in the first place. Authorization, which decides what an authenticated account may do, comes later still.

Strong proofing uses evidence that is hard to fake or look up, such as inspecting a government-issued photo ID and matching it to the live person, in person or on a live video call, and comparing it with records collected during hiring. Weak proofing relies on knowledge-based checks: facts about the person, such as a home address, a mother's maiden name or details from a public professional profile. Such facts leak in breaches or can be researched, so they prove little about who is actually present.

Proofing matters most at recovery. A help desk that resets a password or MFA registration for any caller who knows an employee's details turns social engineering into account takeover. The reset is only as strong as the proofing behind it, so high-value resets (MFA, privileged accounts) should require re-proofing such as a live ID check. Proofing is the step that establishes that the requester is the person claimed; authorization and auditing assume that step has already happened.

Single sign-on (SSO) lets a user authenticate once and reach many applications without signing in again; federation extends that across organizations by having each organization's identity provider (IdP) trust the other's. With federation, a user signs in at home with their own account, and the partner's application accepts that sign-in; neither side creates or manages accounts for the other's people. A useful test is who manages the accounts: if your organization ends up creating, copying or sharing accounts for the partner's people, the arrangement is not federation.

The objective names three protocols. They do different jobs, and questions usually turn on which job the scenario describes.

OAuth is authorization, not authentication

An OAuth access token says that some application was authorized to call an API; it is not a statement, addressed to your application, about who the user is. An app that treats any valid access token as proof of identity can be fooled by a token issued to a different app. OpenID Connect (OIDC) is the identity layer built on OAuth 2.0: it adds an ID token (a signed JSON Web Token naming the user and the intended application), which is what "Sign in with…" buttons should rely on. The fix is to validate the ID token (signature, issuer and audience) rather than treat an access token as proof of who the user is.

Securing LDAP

An LDAP simple bind sends the username and password as given. Over plain LDAP on TCP 389 they cross the network in cleartext and show up in a packet capture. Protect binds with TLS: LDAPS on TCP 636, or StartTLS, which upgrades a connection on port 389 to TLS.

Two near-neighbours often appear as distractors: Kerberos issues tickets for services inside a Kerberos realm, such as an Active Directory domain, and RADIUS authenticates network access such as VPN and Wi-Fi. Neither involves browser redirects with XML assertions or third-party consent screens.

Each account type carries a different risk, so each gets different controls. A user account belongs to one named person for day-to-day work and should never hold administrative rights; administrators get a separate privileged account for admin tasks.

Privileged accounts: global and local

A global privileged account has rights across a whole domain, forest or cloud tenant (a domain administrator or tenant global administrator); a local privileged account has rights on one system only (a workstation's built-in administrator). Scope privilege to the task: desktop support rarely needs domain-wide rights, and granting them widens the blast radius of one stolen credential.

A local account only stays local if its password is unique. When every workstation is built from an image with the same local administrator password, stealing it from one machine unlocks all of them, and attackers move laterally with it; in effect it has become a global credential. The fix is a unique, automatically rotated local admin password per machine, which is what tools such as Windows LAPS (Local Administrator Password Solution) provide. Any change that leaves one secret valid on many machines keeps the lateral-movement path open; the property that matters is uniqueness per machine.

Service accounts

Service accounts run applications, scheduled jobs and services rather than people. They should be non-interactive (no desktop sign-in), least-privileged, and use credentials that the system manages and rotates automatically, so no person knows the password. Managed or group managed service accounts in Active Directory, and workload identities or managed identities in the cloud, do this. The principle is to remove human knowledge of the secret and remove humans from its rotation. Controls designed for people, such as interactive sign-in prompts or manual change schedules, either cannot apply to an unattended process or risk breaking it.

Third-party accounts

Third-party (vendor, contractor or partner) accounts should be individually named, sponsored by an internal owner, limited to what the engagement needs, and time-limited. Accountability needs one account per individual: however well a shared login is hardened, it still cannot attribute an action to a person. For a fixed-term engagement, set an account expiration date at creation so the account stops working on the end date even if nobody remembers to remove it.

Emergency access (break-glass) accounts

Emergency access accounts exist for when normal administration is impossible, such as a failed federation IdP, a broken MFA provider or a misconfigured conditional access policy. Their defining property is independence: an emergency account for a cloud tenant should be cloud-only, not federated through the on-premises IdP and not dependent on the MFA service that might fail. Because they bypass normal controls, they are protected with very strong credentials (often phishing-resistant keys kept in a safe), held by few people, never used for routine work, and every use raises an alert. Test any proposed emergency path by asking whether it relies on the component that has failed; if it does, it is not an emergency path.

Multifactor authentication (MFA) requires factors from at least two different categories: something you know (password, PIN, security answer), something you have (phone, token, smart card, security key) and something you are (fingerprint, face, iris). Two items from the same category are still single-factor, however many there are: two secrets the user remembers are both something you know. A check that proves a human is present without identifying which human is not an authentication factor at all.

Hard tokens, soft tokens and one-time passwords

A hard token is a dedicated physical device (a key fob that displays codes, a smart card, a FIDO2 security key). A soft token is software, typically an authenticator app on a phone. Both commonly produce one-time passwords (OTPs):

Choose the factor for the environment by asking what each method depends on. Anything delivered over a network or to a personal phone needs that network or phone at the moment of sign-in; a self-contained device that computes codes from its own secret and counter or clock does not. SMS codes are the weakest common option because SIM swapping and interception can redirect them.

Biometrics

Biometrics are something you are. The trait is always with the user and is not transferable, but it also cannot be reissued: if a template is stolen, the user cannot get a new fingerprint the way a compromised card is revoked and replaced. Biometric systems also trade false acceptance against false rejection, and need suitable sensor hardware wherever they are used.

Backup codes

Backup codes are a set of single-use recovery codes generated when a user enrols in MFA and stored safely offline (printed and locked away, or in a password manager). They let a user who has lost a phone or security key sign in without calling the help desk, and they do not depend on a phone number, so SIM swapping cannot steal them.

Phishing resistance

The dividing line is whether the credential is bound to the site's origin. Anything the user reads and enters, or approves on a prompt, can be relayed by a real-time adversary-in-the-middle phishing proxy, because the user cannot tell the proxy from the real site; that holds however the code is generated or delivered. Only origin-bound methods, FIDO2/WebAuthn security keys and passkeys, resist this, because they sign a challenge only for the domain they were registered with (see the password concepts section).

An access control model is the rule set a system uses to decide who may do what. Each model answers "who decides?" or "what condition decides?" differently, and the scenario's wording usually gives it away.

The near twins

• Rule vs role: if the condition is the same for every role (source network, time, protocol), it is rule-based; if permissions follow the job, it is role-based.
• MAC vs DAC: labels and clearances enforced by the system, beyond the owner's control, are mandatory; an owner choosing is discretionary.
• Time-based vs JIT: a schedule opens the window in time-based control; a request (and approval) opens it in just-in-time. JIT is the way to remove standing privilege: nobody holds admin rights permanently, yet anyone eligible can obtain them when needed, and they expire automatically. Any arrangement in which someone holds the privilege between uses, however restricted, still has standing privilege. JIT is usually delivered by a privileged access management (PAM) or privileged identity management tool, which also records each elevation.

Access management is the ongoing process of authenticating users, enforcing the policies that say what they may reach, and periodically checking that the result is still right. Authentication proves an identity (with the factors above); authorization then applies the model and policies to decide what that identity may do.

Logical/technical vs administrative/business policies

The objective splits access policies by how they are enforced:

• Logical/technical policies are enforced automatically by a system: firewall rules, file-system permissions, an automatic session timeout, a data loss prevention rule that blocks an upload.
• Administrative/business policies are rules and processes that people follow: an acceptable use policy, a background-check requirement before hiring, a joiner-mover-leaver procedure, separation-of-duties rules, signed agreements with vendors.

The test is simple: if a system enforces it, it is logical/technical; if people carry it out as a process, it is administrative/business. Most good programs pair the two, for example a business rule that access needs owner approval, enforced technically by a request workflow.

Access review (recertification)

An access review, or recertification, has the people who understand the access (managers and data or application owners) periodically confirm that each account and each specific entitlement is still needed, and remove what is not. It catches both classic problems at once: orphaned accounts left by leavers, and privilege creep from movers. A review only works if it checks the right thing. A check that asks only whether the account holder still works here will never flag a mover's leftover rights, because the mover is still employed. The review must examine entitlements, and it must be done by someone who knows what the job needs. An HR-driven leaver process is still valuable, but it handles departures only.

Passwordless authentication signs users in without a shared secret that the server stores and the user types; the main standard is FIDO2, made of the W3C WebAuthn API and the FIDO CTAP protocol. A passkey is a FIDO2 credential: a public/private key pair created for one website or application, with the private key held by the user's device, platform or security key, and only the public key registered with the server.

Why passkeys resist phishing and database theft

• Origin binding: at sign-in the server sends a challenge and the authenticator signs it with the private key registered for that exact domain. A look-alike proxy site is a different origin, so the authenticator will not produce a signature for it, and there is no code for the user to type into the fake page and for the attacker to relay.
• Nothing reusable on the server: the server stores only public keys, which cannot sign challenges. A stolen authentication database gives attackers nothing to replay. By contrast, any scheme in which the server holds a password-derived value or a shared secret leaves something an attacker can crack offline or use to compute valid responses.

The local PIN or biometric

In passwordless sign-in such as Windows Hello for Business or a passkey on a phone, the user unlocks the device-bound private key with a PIN or biometric. The PIN is a gesture to the local authenticator, not a secret the server verifies; it releases a private key that never leaves the device. A short PIN is therefore not equivalent to a short password: someone who learns it still needs the physical device, and the device limits guessing. Passkeys can be device-bound (a security key) or synced across a user's devices by the platform's credential manager; synced passkeys trade some assurance for easier recovery.

Where passwords remain, current guidance (NIST SP 800-63B Rev. 4, 2025) favours length over complexity, changes only on evidence of compromise, and screening against known-breached passwords. A password manager makes that practical: it generates and stores a unique, long, random password for every site, so users neither memorise nor reuse them. It covers the applications that are not behind single sign-on. Rules enforced by one system can only see passwords on that system, so they cannot detect reuse elsewhere; only unique generated passwords remove it.

The best-practice settings, one by one

None of these settings ends a temporary account; that is an account expiration date, not a password one.

Compromised credential monitoring, account auditing and policy reports

Three related activities are easy to confuse:

• Compromised credential monitoring watches external sources (breach dumps, paste sites, criminal markets) for the organization's usernames and passwords, including passwords reused on third-party sites that later suffer a breach, and alerts so those passwords can be reset.
• Account auditing examines the organization's own accounts against expectations (activity, privilege level, password settings, ownership) and flags any that cannot be justified.
• A password policy report compares the configured password settings (length, history, lockout and so on) with the organization's standard, showing where systems are out of policy.

An access review differs from all three: it asks owners whether access is still needed. Identity proofing is about the person before an account exists.