Reviewed September 2026 NIST SP 800-63 Rev. 4 informed

Build identity controls around the full account lifecycle, not just the login screen.

Identity and access management determines who or what receives access, how that identity is established, how authentication is performed, what permissions are granted, how privileged actions are controlled, and how access is removed when the relationship changes.

NIST finalized SP 800-63 Revision 4 in July 2025, superseding Revision 3 and updating the federal digital-identity guidance for proofing, authentication, and federation. This guide uses that current suite as technical reference while separating federal requirements from generally useful enterprise practices.

Operating model

Separate identity proof, authentication, authorization, and accountability.

Many access failures start when these concepts are treated as one control. Identity proofing establishes confidence that the person is who they claim to be. Authentication demonstrates control of an enrolled authenticator. Authorization decides what the authenticated identity is allowed to access. Accounting and monitoring preserve evidence of what the identity did. Each layer needs an owner and a lifecycle.

Use one authoritative identity lifecycle wherever practical, but do not assume every system can be connected immediately. Start by identifying identity sources, directories, federated applications, local accounts, service identities, privileged accounts, emergency access, third-party accounts, and shared credentials. The first program objective is visibility: know which identity populations exist and which systems can grant consequential access.

The strongest IAM programs reduce standing privilege, use strong authentication where consequence justifies it, remove access quickly when roles change, and make exceptions visible. Technology helps, but the operating model depends on HR or workforce events, service ownership, application roles, procurement, vendor management, and security monitoring working together.

Joiner, mover, leaver

Make access follow the relationship.

Joiners

Provision from an authoritative source rather than free-form email requests where possible. Record the sponsor, employment or contract status, department, role, start date, required systems, and expiration date for temporary relationships. Default access should be narrow enough that a new account does not inherit permissions unrelated to the job.

For external users and contractors, make the sponsor accountable for continued need. Require an explicit end date when the relationship is naturally time-bounded.

Movers

Role changes are a major source of privilege accumulation. A promotion or transfer should not only add the new role; it should trigger review of access that belonged to the old one. Where practical, separate baseline access, job-role access, and exceptional access so reviewers can see why each entitlement exists.

Leavers

Termination and contract-end events need a documented disablement path with timing appropriate to risk. Remove interactive access, revoke sessions and tokens where supported, recover managed devices, transfer ownership of service resources, rotate credentials that were shared with the departing person, and review delegated access or mailbox rules.

Dormant and orphaned accounts

Detect accounts with no valid owner, stale logins, expired sponsors, or systems that no longer have a business purpose. Disabling an account should be safer than deleting evidence immediately; preserve records needed for audit, investigation, legal hold, or service ownership before final deletion.

Authentication

Match authentication strength to the consequence of account takeover.

NIST SP 800-63B-4 defines authenticator-assurance requirements for federal digital identity. Enterprise programs can use the same risk logic without claiming a federal assurance level unless they actually meet the applicable requirements.

Prefer phishing-resistant MFA for high-value access

CISA recommends aiming for phishing-resistant MFA, especially for privileged and remote access. FIDO/WebAuthn security keys and platform authenticators can resist credential phishing because authentication is bound to the legitimate service origin rather than a code that a user can relay to an attacker.

Roll out the strongest methods first to administrators, identity systems, remote access, email, cloud control planes, finance, and other high-consequence accounts. Keep recovery procedures at least as strong as the authentication they recover; a help-desk bypass can become the weakest path into an otherwise strong account.

Password policy should not create predictable workarounds

Do not rely on complex composition rules as the main defense. Use long passwords or passphrases, screen new passwords against compromised or disallowed values where the platform supports it, protect stored verifiers, throttle online guessing, and pair passwords with stronger authentication for consequential access.

Rotate credentials when there is evidence or reasonable suspicion of compromise, when shared credentials must be recovered, or when a lifecycle event requires it. Arbitrary frequent changes can encourage predictable patterns without addressing phishing or token theft.

Protect sessions after login

Authentication is not finished when a password is accepted. Define session lifetimes, idle behavior, reauthentication triggers, token protection, device requirements, and revocation behavior. Sensitive actions may justify fresh authentication even when a user already has a session.

Design recovery as part of authentication

Account recovery should establish enough confidence that an attacker who stole public information cannot simply reset the account. Limit help-desk overrides, verify high-risk recovery actions, notify the user of material changes, and record recovery events for investigation.

Authorization

Make every meaningful entitlement explainable.

Role-based access control is useful when job functions are stable enough to define repeatable permission bundles. Attribute- or policy-based models can add device, location, resource, risk, or relationship context where the system supports it. The important requirement is not a specific model; it is the ability to explain why an identity has access and who approved it.

Separate basic account existence from entitlement. A directory account may be valid while a specific application role is not. Maintain owners for sensitive groups and application roles, and require those owners to review membership on a schedule appropriate to risk. High-volume reviews should be risk-ranked rather than asking managers to approve hundreds of opaque entitlements they cannot understand.

Detect toxic combinations and segregation-of-duties conflicts where one identity can initiate and approve the same sensitive transaction. Do not assume a job title alone guarantees correct access. Use actual entitlements and workflow authority when evaluating conflicts.

Privileged access

Reduce standing administrative power and make use attributable.

Separate admin from daily work

Administrators should not browse the web, read routine email, or perform ordinary productivity work while using high-privilege identities. Separate accounts or elevation mechanisms reduce the chance that a compromised everyday session immediately becomes an infrastructure compromise.

Use just-in-time or time-bounded elevation

Where platforms support it, grant privileged roles only for the window needed to complete approved work. Require a reason, ticket or task reference, strong authentication, and logging. Shorter standing access reduces the window available to an attacker who compromises an account.

Protect emergency access

Break-glass accounts should exist only where needed, use strong credentials protected outside the normal dependency path, be monitored for any use, and be tested periodically. Every use should create a review and credential-reset action.

Record privileged activity

Centralize authentication, elevation, configuration change, and sensitive administrative events. A privileged account that cannot be tied to an individual or approved automation path is difficult to govern and investigate.

Workload and service identities

Machine identities need owners and rotation just as human accounts do.

Service accounts, API credentials, application secrets, certificates, managed identities, CI/CD tokens, cloud roles, and automation keys can carry broad permissions for long periods. Inventory them with an application or service owner, purpose, environment, granted permissions, authentication method, storage location, rotation mechanism, expiration where supported, and dependency map.

Prefer short-lived credentials and platform-managed identities over embedded static secrets when the architecture supports them. Do not place production credentials in source code, build logs, ticket text, or shared documents. Use a secrets-management system with access controls and audit evidence appropriate to the consequence of disclosure.

Remove unused credentials and rotate credentials after ownership changes, suspected exposure, or a dependency compromise. When a service account cannot be rotated safely, treat that limitation as technical debt and document the recovery plan before an incident forces an untested credential change.

Federation and SSO

Centralize trust deliberately, then protect the trust anchor.

Federation reduces password sprawl

Federated authentication can let applications rely on a central identity provider instead of maintaining separate passwords. That improves lifecycle control when disabling the authoritative identity also removes application access. It also concentrates risk: compromise or misconfiguration of the identity provider can affect many relying systems.

Validate trust configuration

Document each relying party, federation protocol, signing/encryption keys, redirect or assertion endpoints, expected audience, claim mappings, privileged groups, and logout/session behavior. Remove abandoned applications and stale trust relationships rather than leaving them attached indefinitely.

Limit claim and group sprawl

Applications should receive only the identity attributes they need. Review group-to-role mappings carefully; a broad directory group mapped to an administrative application role can turn an innocent directory change into a privilege escalation.

Plan identity-provider resilience

SSO creates dependency. Define what happens when the identity provider, MFA service, network path, certificate, or federation metadata becomes unavailable. Critical systems may need controlled emergency access that does not silently become the normal path.

Evidence and metrics

Measure whether access is becoming more bounded and attributable.

MFA coverage: percentage of workforce, remote, privileged, and high-consequence accounts protected by the required authentication strength.
Phishing-resistant MFA coverage: separately measure accounts using methods designed to resist credential relay and fake login pages.
Provisioning time: time from approved start event to required access, without encouraging overprovisioning.
Deprovisioning time: time from termination or contract end to disabled interactive access and revoked privileged roles.
Standing privilege: number of identities holding persistent administrative roles compared with time-bounded elevation.
Orphaned identities: accounts or credentials without a valid owner, sponsor, or active service dependency.
Access-review findings: removals, conflicts, expired exceptions, and unexplained entitlements identified through review.
Authentication-risk events: suspicious sign-ins, recovery events, disabled MFA, new authenticators, and privileged-session anomalies.

Metrics should lead to decisions. If deprovisioning is slow, identify the systems that cannot consume lifecycle events. If access reviews remove almost nothing, test whether reviewers understand the entitlements. If privileged MFA coverage is high but recovery bypasses it, measure the recovery path instead of declaring the control complete.

90-day implementation

Start with consequential identities and lifecycle gaps.

Days 1–30: map identity systems

Inventory identity providers, directories, privileged platforms, local-account populations, external users, service accounts, federated applications, lifecycle feeds, MFA methods, and emergency-access paths. Identify systems where termination cannot quickly remove access.

Days 31–60: strengthen high-risk access

Move administrators and remote access toward phishing-resistant MFA where supported, reduce shared accounts, establish privileged elevation, define sponsor/expiration rules for external users, and create an owner for sensitive application roles.

Days 61–90: automate and prove the lifecycle

Connect joiner/mover/leaver events, build access-review evidence, inventory service identities, test termination and emergency-access scenarios, and report the gaps that still require manual intervention or platform modernization.

Program review questions

Can the organization explain who approved each consequential entitlement?
Can termination remove access across cloud, SaaS, on-premises, and local-account systems within the required window?
Are administrators using phishing-resistant authentication and separate privileged workflows?
Are service identities owned, least-privileged, rotated, and visible in monitoring?
Can the team identify and disable an abandoned federation trust or application integration?
Is account recovery strong enough that it does not bypass the primary authentication controls?

Primary sources

Keep identity decisions tied to current guidance.

NIST SP 800-63 contains federal digital-identity requirements and recommendations. Organizations outside its direct scope should use the guidance as technical reference while applying their own legal, contractual, and risk requirements.

Continue learning

Related guides after Identity & Access Management Program

Follow the next implementation topic without returning to search.

Turn Identity & Access Management Program Guide: MFA, Federation, PAM & Lifecycle | Zeph Tech into a decision-ready next step.

Use the source-backed research to pressure-test assumptions, then build a reusable evaluation brief before you compare products, scope implementation, or request a fit review.

Build an evaluation brief Browse the research archive Explore the full resource library See where ZephCMS may fit