NIST SP 800-63-4: Password, MFA and Passkey Evidence

At 08:10 on a Monday, a fintech CISO receives the message every security leader dreads: “We have suspicious logins against the finance admin portal. MFA was approved, but the user says it was not them.”

By 08:25, the SOC sees the pattern. The attacker did not break encryption, exploit a zero-day or bypass a firewall. They phished a password, triggered a push prompt and waited for fatigue. One approval was enough. The account had elevated access to customer billing exports, audit logs and a third-party settlement dashboard.

By 09:00, legal is asking whether this is a GDPR personal data breach. The risk team is asking whether the event triggers DORA reporting. The board wants to know whether the company’s “MFA everywhere” statement was actually true. The ISO 27001 auditor, already scheduled for next month, now wants evidence of secure authentication, access control, logging and corrective action.

This is why NIST SP 800-63-4 matters in 2026.

For CISOs, compliance managers and business owners, NIST SP 800-63-4 is not just another identity document. It is becoming the practical reference for modern password policy, phishing-resistant MFA, passkeys, passwordless authentication and authenticator lifecycle governance. The real challenge is not reading the guidance. The challenge is proving implementation across ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 and internal audit expectations.

Clarysec’s position is simple: identity controls fail when they are treated as settings, not governance. Passwords, MFA, passkeys, recovery flows, session tokens, privileged access, service accounts and authentication logs must be designed as one evidence-producing control system.

That is the lens used in Zenith Blueprint: An Auditor’s 30-Step Roadmap, in Clarysec’s policy library and in Zenith Controls: The Cross-Compliance Guide. Zenith Controls does not create new controls. It maps ISO/IEC 27001:2022 and ISO/IEC 27002:2022 control expectations across other standards, regulations and audit viewpoints so organizations can avoid fragmented evidence and duplicated compliance work.

“MFA Enabled” Is Not an Audit Answer

Many organizations entered the last few years believing that MFA deployment closed the identity risk conversation. In 2026, that assumption is unsafe.

Auditors and regulators now ask sharper questions:

• Is MFA enforced for all privileged, remote and high-risk access?
• Is authentication phishing-resistant where the risk requires it?
• Are passkeys or FIDO2 authenticators governed through enrollment, recovery, revocation and device lifecycle?
• Are passwords screened against breached and common credential lists?
• Are password changes triggered by compromise rather than arbitrary calendar rotation?
• Can users paste passwords from password managers?
• Are authenticator events logged and reviewed?
• Are account recovery flows as strong as login flows?
• Are API secrets, OAuth tokens, SSH keys and service account credentials controlled with the same discipline?

NIST SP 800-63-4 pushes organizations toward risk-based digital identity assurance, authenticator strength and lifecycle evidence. For password modernization, this means moving away from outdated habits such as forced periodic password changes where there is no indication of compromise, while strengthening length, breached-password screening, rate limiting, secure storage and recovery controls. For MFA and passkeys, it means focusing on authenticator assurance, phishing resistance, secure enrollment, binding to the account, revocation and auditability.

Zenith Blueprint captures this shift in Controls in Action, Step 19, Technological Controls I, when discussing secure authentication:

Authentication is the first and most critical line of defense between a threat actor and your systems, data, and services. If authentication is weak, everything else, encryption, monitoring, segmentation, can be bypassed. Control 8.5 ensures that authentication mechanisms are securely designed, consistently applied, and resistant to known attack methods.

That sentence is the heart of the 2026 identity audit. The question is no longer “Do you have passwords and MFA?” The question is “Can you prove your authentication architecture is risk-based, resistant to known attack methods, consistently enforced and monitored?”

Build the Control System Around Identity, Authentication Information and Secure Authentication

The most useful way to translate NIST SP 800-63-4 into ISO/IEC 27001:2022 evidence is to treat identity as a connected control system.

Through Zenith Controls, Clarysec identifies three central ISO/IEC 27002:2022 control areas for NIST SP 800-63-4 alignment: 5.16 Identity management, 5.17 Authentication information and 8.5 Secure authentication. In ISO/IEC 27001:2022 Annex A, these are A.5.16, A.5.17 and A.8.5.

The distinction matters. A.5.16 asks, “Who has an identity?” A.5.17 asks, “How is proof of that identity protected?” A.8.5 asks, “How is authentication securely performed in systems?”

When organizations fail audits, it is often because they implement one layer without the others. They deploy passkeys, but cannot show revocation evidence. They enforce MFA, but not for a legacy admin console. They set password rules, but do not screen for breached passwords. They disable a user account, but forget active sessions or recovery tokens.

In Zenith Blueprint, Controls in Action, Step 22, Organizational controls, Clarysec explains A.5.17 as a lifecycle issue:

If identity is the question, “Who are you?” , then authentication is the proof. Control 5.17 is where theory meets trust. It requires that authentication information be managed securely throughout its entire lifecycle , ensuring that the methods and credentials used to verify identity cannot themselves become the weakest link.

A passkey is not compliant because it exists. It becomes defensible when you can show how it is enrolled, bound, protected, recovered, revoked, logged and reviewed.

Modernize Passwords Without Losing Audit Traceability

Many companies still have password policies written for a different threat model. “Twelve characters, symbols, change every 90 days” is familiar, but familiarity is not the same as resilience.

NIST SP 800-63-4 reinforces a more modern approach: longer passwords and passphrases, screening against breached or commonly used passwords, rate limiting, secure reset, no arbitrary periodic changes unless compromise is suspected and user-friendly controls that support password managers. This does not mean every organization must rewrite every policy overnight. It means password requirements should be risk-based, technically enforced and reconciled with ISO 27001 evidence.

Clarysec’s SME policy library gives smaller organizations a practical baseline that can be improved as they mature. The User Account and Privilege Management Policy - SME states:

Passwords must meet complexity requirements (e.g., at least 12 characters, alphanumeric with symbols) and be changed at least every 90 days.

This is a useful enforceable starting point for SMEs. However, a 2026 NIST SP 800-63-4 modernization project should review whether fixed 90-day expiry remains appropriate for each system, especially when MFA, breached-password screening, strong password length and compromise-triggered reset workflows are in place. In practice, many organizations retain the baseline during transition, then add a password modernization addendum approved through risk treatment and the Statement of Applicability.

For enterprise environments, Clarysec’s User Account and Privilege Management Policy provides a governance hook rather than hardcoding every password rule:

All user accounts must enforce password complexity and expiration in accordance with the organization’s Password Policy.

That language allows the CISO to update the Password Policy to align with NIST SP 800-63-4 without rewriting the entire access management framework.

A practical password modernization evidence pack should include:

• Current password policy and approved modernization addendum.
• IdP configuration showing minimum length, maximum length and allowed characters.
• Evidence that password managers are permitted, including paste functionality where relevant.
• Breached, weak and common password screening configuration.
• Rate limiting or lockout policy for online guessing attacks.
• Password reset workflow requiring adequate identity verification.
• Password hash storage architecture for applications that store credentials.
• Exception register for legacy systems unable to support modern settings.
• Compromise-triggered reset procedure with incident response linkage.
• User communication and training evidence.

The goal is not to win a debate about one password length. The goal is to demonstrate that password authentication is controlled, measurable and integrated into the ISMS.

Move MFA and Passkeys From “Second Factor” to Assurance

The Monday morning incident started with MFA fatigue. That is why auditors increasingly ask whether MFA is phishing-resistant, not just present.

Traditional MFA methods such as SMS, email OTP, TOTP apps and push notifications can reduce risk, but they are not equal. Passkeys and FIDO2/WebAuthn authenticators provide stronger resistance to phishing because authentication is bound to the legitimate origin and uses public key cryptography. For high-risk users, privileged administrators, finance approvers, developers with production access and remote access pathways, phishing-resistant MFA should be treated as the target state unless there is a documented and approved exception.

Clarysec’s enterprise Secure Communications and Multi-Factor Authentication (MFA) Policy sets the baseline:

Multi-Factor Authentication (MFA): All access to the organization’s network and information systems, particularly privileged access or remote access, shall require Multi-Factor Authentication (MFA) (e.g., password plus OTP token or biometric factor). Multi-Factor Authentication (MFA) solutions shall align with industry best practices (e.g., time-based one-time codes or hardware keys) and shall be configured to protect against unauthorized access.

For SMEs, the Access Control Policy - SME states:

Privileged accounts must use multi-factor authentication (MFA) where supported.

The phrase “where supported” gives SMEs a realistic implementation path, but it also creates an audit obligation. If a privileged system does not support MFA, the organization should document compensating controls such as network restrictions, privileged access management, jump hosts, shorter sessions, monitoring, vaulting and a migration plan.

Zenith Blueprint, Controls in Action, Step 19, is direct about the direction of travel:

Where possible, password-only authentication should be avoided , especially for administrative accounts, cloud consoles, remote access tools, and any system exposed to the internet. MFA, using a second factor like a hardware key, mobile app, or biometrics, is now a baseline, not a luxury.

Passkeys fit naturally into this narrative. A passkey rollout should not be presented as a technology upgrade only. It should be documented as a risk treatment for phishing, credential stuffing, MFA fatigue, password reuse and account takeover.

The Passkey Evidence Model Auditors Need

Passkeys can be syncable, device-bound, hardware-backed, platform-based or roaming depending on the authenticator and ecosystem. Assurance depends on enrollment, device trust, recovery, account binding and revocation. A passkey project that lacks evidence can create audit ambiguity even when the technology is strong.

Use this model to prepare an audit-ready passkey rollout.

This aligns directly with ISO/IEC 27001:2022. Clauses 4.1 to 4.4 require organizations to understand context, interested parties, ISMS scope and operating processes. Clauses 5.1 to 5.3 require leadership, policy, organizational roles and accountability. Clauses 6.1.2 and 6.1.3 require a repeatable information security risk assessment and risk treatment process, including control selection, comparison with Annex A, a Statement of Applicability and risk-owner approval of residual risk. Clause 6.2 requires measurable information security objectives.

That means a passkey rollout should appear in the ISMS as:

• A risk treatment for credential theft and phishing.
• An objective, such as “90 percent of privileged access migrated to phishing-resistant MFA by Q3.”
• A Statement of Applicability rationale linked to A.5.16, A.5.17 and A.8.5.
• An access control policy update.
• A logging and monitoring use case.
• An audit evidence pack.

In Zenith Blueprint, Risk Management phase, Step 13, Risk Treatment Planning and Statement of Applicability, Clarysec describes the SoA as a bridge:

The SoA is effectively a bridging document : it links your risk assessment/treatment to the actual controls you have. By completing it, you also double-check if you missed any controls.

For NIST SP 800-63-4, that bridge is where password, MFA and passkey decisions become auditable.

Cross-Compliance Mapping for ISO 27001, NIS2, DORA, GDPR, NIST CSF and COBIT

Identity evidence becomes powerful when one control set satisfies several obligations.

NIS2 Article 21 requires essential and important entities to implement appropriate and proportionate technical, operational and organizational measures reflecting risk, state of the art, implementation cost, size and incident impact. Article 21(2) includes risk analysis, policies, incident handling, business continuity, supply chain security, secure development, assessment of control effectiveness, cyber hygiene and training, cryptography, HR security, access control, asset management and, where appropriate, multi-factor or continuous authentication. Article 20 makes management approval, oversight and cybersecurity training a governance obligation.

DORA brings the same identity topic into financial operational resilience. Covered financial entities must maintain a documented ICT risk management framework with management body responsibility, protection and prevention controls, access control, authentication, monitoring, anomaly detection, continuity, response, recovery and training. Articles 8 to 10 are especially relevant to identifying ICT assets and dependencies, protecting ICT systems, access control, strong authentication, monitoring and detection. Articles 17 to 19 connect the same evidence to ICT-related incident management and reporting.

GDPR applies wherever personal data is processed within its territorial and material scope. Article 5(1)(f) requires personal data to be processed with appropriate security. Article 5(2) requires accountability. Article 32 requires appropriate technical and organizational measures to ensure a level of security appropriate to risk. A stolen password or compromised authenticator can become a personal data breach if it causes unauthorized access to personal data.

NIST CSF 2.0 adds a useful management overlay. Its GOVERN Function requires legal, regulatory and contractual cybersecurity requirements, including privacy obligations, to be understood and managed. CSF Profiles help organizations compare current and target states and create prioritized action plans.

COBIT 2019 and ISACA audit approaches ask whether identity and access controls support governance objectives, whether management practices are defined, whether authentication strength matches risk and whether control operation is evidenced.

The same IdP conditional access report can support ISO 27001 access control, NIS2 MFA, DORA authentication, GDPR security accountability and NIST CSF target profile progress.

Build an Authenticator Evidence Pack in One Afternoon

A CISO, compliance manager or IT lead can create a high-value evidence pack quickly by focusing on one high-risk system, such as a cloud console, finance platform, customer admin portal or production deployment environment.

First, define the scope. Identify the business owner, data classification, user groups, privileged roles, remote access paths, current authenticators, personal data involved and third-party dependencies. This supports ISO/IEC 27001:2022 Clauses 4.1 to 4.4 because scope, interested-party requirements and dependencies must be understood.

Second, capture current authentication settings. Export or screenshot the password policy, MFA enforcement, passkey or FIDO2 configuration, conditional access rules, session timeout, recovery methods, break-glass accounts and legacy authentication status. If the system uses local authentication, document why and define a migration path.

Third, compare against a clear target state:

• Passwords screened for weak, common and breached credentials.
• No password-only access for privileged, remote or internet-exposed systems.
• Phishing-resistant MFA for administrators and high-risk users.
• Secure enrollment and recovery.
• Revocation of authenticators during termination or device loss.
• Logging of successful and failed authentication, MFA use and authenticator changes.
• Alerts for impossible travel, repeated failures, new authenticator enrollment and risky sign-ins.

Fourth, attach policy evidence. The SME Access Control Policy - SME requires:

Unique usernames are required; shared accounts are prohibited.

For account lifecycle evidence, the SME User Account and Privilege Management Policy - SME states:

Logs of account creation, account deactivation, and privilege changes must be securely retained for at least 12 months.

For authentication logging, Clarysec’s Logging and Monitoring Policy - SME specifies:

Authentication logs: Successful and failed login attempts, session duration, MFA usage

For enterprise implementations, the Logging and Monitoring Policy requires logging of:

User authentication and access attempts

Fifth, update the Statement of Applicability. Mark A.5.16, A.5.17 and A.8.5 as applicable and add notes such as:

• Supports NIST SP 800-63-4 authenticator lifecycle expectations.
• Supports NIS2 Article 21 access control and MFA expectations.
• Supports DORA ICT risk management authentication and monitoring requirements.
• Supports GDPR Article 32 security and accountability for personal data access.
• Exception: legacy settlement portal lacks FIDO2 support. Compensating controls include VPN restriction, privileged session monitoring, vendor remediation plan and monthly access review.

Finally, prepare a folder called “Authentication Evidence Pack - Q2 2026” with policy extracts, risk assessment, treatment record, SoA extract, IdP configuration, MFA and passkey coverage report, privileged user list, exception register, enrollment and revocation logs, termination test sample, SIEM queries, alert screenshots, incident response playbook extract and user awareness communication.

That is the difference between “we use MFA” and “we can prove secure authentication governance.”

How Different Auditors Will Test the Same Identity Controls

A mature identity program anticipates different audit viewpoints.

The ISO 27001 auditor will start with the management system. They will ask how identity risks were assessed, why controls were selected, how they appear in the SoA, whether policies are approved, whether responsibilities are assigned and whether evidence shows operation over time. They will test consistency between the risk register, access control policy, IdP settings and logs.

Zenith Blueprint, Controls in Action phase, Step 19, Audit Checklist for Controls 8.1 to 8.5, describes the practical audit ask:

Auditors will inquire about password complexity settings and how they are enforced (Active Directory GPOs, IdP policies, etc.). Show documentation on MFA deployment, who it applies to, where it’s enforced, and what systems are protected.

A DORA or NIS2 auditor will focus on governance, resilience and systemic risk. They may ask for board or management body oversight, critical system coverage, third-party authentication obligations, continuity tests and evidence that recovery procedures can only be initiated by authenticated personnel.

A GDPR reviewer will focus on personal data. They will ask whether authentication protects personal data from unauthorized access, whether access is limited to what is necessary, whether logs support breach assessment and whether the organization can demonstrate accountability.

A NIST-oriented assessor may use NIST CSF 2.0 Profiles to compare current and target states. They will want a prioritized action plan covering governance, policy, access control, detection and response outcomes.

A COBIT 2019 or ISACA auditor will evaluate whether identity and authentication practices support governance objectives, control design, control operation, segregation of duties, privileged access and monitoring. They may not care what brand of passkey you use. They will care whether the control is governed, measured, owned and improved.

Do Not Forget Termination, Recovery and Non-Human Identity

Many authentication programs look strong at login and weak everywhere else.

Termination is a common failure point. Clarysec’s Onboarding and Termination Policy specifically includes:

revocation of MFA/SSO tokens, smart cards, or certificates

That clause should be tested. Select three terminated users and prove that accounts, sessions, MFA devices, passkeys, certificates and recovery methods were revoked on time. If you cannot prove token revocation, your termination control is incomplete.

Recovery is another weak point. If a helpdesk can reset MFA after answering two easy questions, the attacker will target helpdesk recovery instead of login. Recovery procedures should require strong verification, ticket logging, approval for privileged users, user notification and monitoring of post-recovery activity.

Non-human identity is the third blind spot. Zenith Blueprint Step 22 makes clear that authentication information includes “passwords, PINs, cryptographic keys, biometric templates, smartcards, tokens, certificates, OAuth tokens, SSH keys, API secrets.” Attackers frequently use API tokens, service account keys and OAuth grants to persist. Treat those credentials under A.5.17, with vaulting, ownership, rotation, revocation and logging.

What Good Looks Like in 2026

A mature 2026 identity control environment has these characteristics:

• The board or management body understands identity risk and approves the direction.
• Password policy is modernized, user-friendly and technically enforced.
• Password-only access is eliminated for privileged, remote and internet-exposed systems.
• Passkeys or FIDO2 authenticators are prioritized for high-risk access.
• MFA exceptions are documented, approved, time-limited and compensated.
• Authenticator enrollment, recovery and revocation are controlled.
• Termination includes account, token, certificate, session and passkey revocation.
• Authentication logs include successes, failures, MFA use, session duration and authenticator changes.
• SIEM use cases detect credential stuffing, impossible travel, suspicious enrollment and MFA fatigue.
• The SoA explains why A.5.16, A.5.17 and A.8.5 apply.
• NIS2, DORA, GDPR and NIST CSF mappings are recorded once and reused.
• Evidence is collected continuously, not assembled in panic before audit.

This is how NIST SP 800-63-4 becomes more than a reference document. It becomes a living control system that supports security, privacy, resilience and audit readiness.

Turn Identity Controls Into Audit-Ready Evidence

If your organization is updating password rules, deploying phishing-resistant MFA, introducing passkeys or preparing for ISO 27001, NIS2, DORA or GDPR audit questions, do not start with tool configuration alone.

Start with the evidence model.

Clarysec can help you:

• Map NIST SP 800-63-4 password, MFA and passkey expectations to ISO/IEC 27001:2022.
• Build an authenticator lifecycle policy and evidence pack.
• Update access control, MFA, logging, onboarding and termination policies.
• Prepare a Statement of Applicability that links identity risk to controls.
• Use Zenith Blueprint to structure implementation steps and audit readiness.
• Use Zenith Controls to cross-map identity controls across NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT 2019.

The best time to discover weak recovery, missing passkey revocation or incomplete MFA enforcement is before the incident, before the regulator and before the auditor asks.

Make your next access control review a NIST SP 800-63-4 evidence review. Download the relevant Clarysec policies, explore Zenith Blueprint and use Zenith Controls to turn password, MFA and passkey implementation into one practical, proportionate and audit-ready compliance story.