Password manager compliance standards: What changed in 2026

In 2026, password manager compliance means proving control over credentials. These password manager compliance standards overlap in places, but they don't add up to one universal policy.

Requirements differ by industry, geography, system scope, and audit boundary, so no single certification covers every organization equally. Framework applicability depends on entity type, system and data scope, jurisdiction, contracts, and risk. This guide gives you a cross-framework standards map, a resolution to the recurring NIST-versus-PCI rotation conflict, and a passkey mapping you can use when writing policy.

Compliance standards for password managers: 2026 status

Compliance evidence is the set of policies, configuration records, approval trails, access reviews, logs, and test results that show a control operates as designed, not just that it exists on paper. For password managers, the 2026 baseline is a governed credential lifecycle: unique identities, controlled vault access, strong authentication, auditable changes, tested recovery, and a framework-specific policy overlay.

No single global law rewrote password manager compliance in 2026. What changed is the combination: 

• NIST (the US National Institute of Standards and Technology) Rev. 4 became the current technical benchmark for authenticators
• PCI DSS (Payment Card Industry Data Security Standard) v4.0.1 is the active PCI standard
• DORA (the EU's Digital Operational Resilience Act) has applied since 17 January 2025
• NIS2 (the EU's second Network and Information Security Directive) moved into national enforcement
• Gap persists between HIPAA's (Health Insurance Portability and Accountability Act) current rule and its proposed multi-factor authentication (MFA) update.

Password manager compliance standards by framework

The Credential Governance Overlay (CGO) maps each framework to the control it demands, the evidence an auditor can test, and the password manager capability that makes the control operational. Each framework below covers what it requires and what that means for vault configuration. The table further down summarizes the evidence to retain for each.

NIST SP 800-63B Rev. 4

For centrally verified passwords, NIST SP 800-63B Rev. 4 sets a 15-character minimum for single-factor authentication. An 8-character minimum applies only when the password is used solely as part of MFA. Verifiers shall not impose composition rules or periodic changes, and shall screen new passwords against known common, expected, or compromised values.

For a password manager, this means generating long, unique credentials, allowing autofill, permitting paste where autofill is unavailable, running compromise detection, and protecting vault authentication with MFA.

ISO/IEC 27001:2022

ISO 27001 is the international standard for information security management systems. Annex A controls A.5.16 (identity management), A.5.18 (access rights), A.8.5 (secure authentication), and A.8.24 (cryptography) flow through the risk treatment plan and Statement of Applicability, a document listing which controls apply and why. These controls are selected through risk treatment; ISO does not mandate every Annex A control or a specific password manager product.

Operationally, this points to a joiner-mover-leaver workflow, role-based access control (RBAC), MFA where risk requires it, and documented encryption and key management.

SOC 2

SOC 2 is an auditing framework for service organizations. AICPA's Trust Services Criteria CC6.1-CC6.8 are outcome-based controls covering access architecture, registration and authorization, access changes, physical protection, secure disposal, boundary protection, authorized transfer or removal of information (CC6.7), and malware defense. Auditors test evidence appropriate to the system boundary, risks, and selected controls.

Treat the vault as one component inside the audited system boundary. Control administrators, exports, integrations, and logging, not passwords alone.

PCI DSS v4.0.1

PCI DSS protects payment-card data. Requirement 8 governs identification and authentication for the cardholder data environment (CDE), the systems and people in scope for payment-card data. Under Requirement 8.3.6, passwords or passphrases used as authentication factors must be at least 12 characters, or at least 8 where the system does not support 12.

Where a password or passphrase is the only authentication factor for user access, Requirement 8.3.9 requires a change at least every 90 days or automatic access decisions based on dynamic analysis of the account's security posture. The requirement may be marked not applicable only where MFA protects access to all in-scope system components, or where the component and access path fall within PCI SSC's defined single-factor conditions. MFA obligations themselves are governed separately, under Requirements 8.4.2-8.4.4, based on the access path.

Segment PCI-scoped credentials, confirm whether Requirement 8.3.9 applies before assuming it doesn't, and check which MFA requirement governs each access path.

HIPAA Security Rule

HIPAA protects health information in the US. Current 45 CFR §164.312 requires access control, unique user identification, an emergency access procedure, and person/entity authentication for electronic protected health information (ePHI) systems. A 2025 HHS proposal would add MFA with limited exceptions, but that requirement remains proposed, not final law.

Use unique vault accounts, preserve emergency-access procedures, restrict ePHI credential sharing, and review access and logs regularly.

NIS2

NIS2 is the EU directive on network and information security. Article 20 requires management bodies to approve and oversee Article 21 measures, and allows liability under applicable national law. Article 21 requires proportionate measures including access-control policies, cryptography, cyber hygiene, and MFA or continuous authentication where appropriate. Article 34 requires member states to set maximum administrative fines of at least €10 million or 2% of worldwide turnover for essential entities, whichever is higher.

This translates into a board-approved risk-management program covering access reviews, training, incident response, and vendor oversight.

DORA

DORA governs ICT risk for in-scope EU financial entities and has applied since 17 January 2025. Article 9 requires ICT security policies and controls, including least-privilege access, strong authentication, and cryptographic-key protections. Article 10 covers detection mechanisms; Article 11 covers ICT business continuity, response, recovery, backup, and restoration.

Treat the vault as an ICT service: test recovery, control privileged access, monitor anomalies, and assess hosted-vendor risk.

GDPR

GDPR is the EU's general data protection law. Article 25 requires data protection by design and default. Article 32 requires security appropriate to risk, including confidentiality, resilience, and tested restoration. Both sit under the accountability principle: the organization must be able to demonstrate compliance, not just claim it.

Map vault data flows, access, telemetry, recovery, retention, and processor or subprocessor relationships.

An enterprise can run one baseline vault policy but must layer stricter scoped overlays where PCI, financial-sector rules, healthcare law, national NIS2 legislation, contracts, or internal risk appetite demand more. That keeps policy manageable without treating a general NIST baseline as a legal override for scoped systems.

Table: password manager compliance controls by framework.

Resolve the NIST-PCI password-rotation conflict by scope

Do not choose between NIST and PCI globally. Apply each standard to the accounts and systems it governs. Scope means the people, systems, data, and processes a given requirement actually applies to, and getting scope wrong is a common source of conflicting password policy inside one organization.

NIST Rev. 4 states that verifiers shall not require periodic password changes. PCI DSS v4.0.1 Requirement 8.3.9 creates a different rule where a password or passphrase is the only authentication factor for user access: change it at least every 90 days or use dynamic security-posture analysis to determine access. The rule may not apply where MFA protects access to all in-scope components, subject to PCI's applicability notes and PCI SSC guidance. The two standards therefore conflict only for the applicable PCI-scoped, single-factor password accounts. They should not be treated as a universal policy conflict.

Use this three-step resolution:

• Maintain a labeled inventory of applications and accounts, including whether each one sits inside the CDE and whether it relies on a password as the sole factor.
• For PCI-scoped, single-factor accounts, confirm whether MFA covers all in-scope components before assuming Requirement 8.3.9 doesn't apply. Where it does apply, enforce the 90-day change or the permitted dynamic-analysis exception.
• Apply NIST's length, blocklist, no-composition, compromise-triggered-change model to non-PCI systems where NIST is the governing baseline.

Confirm the final scope and exception mapping with your organization's PCI assessor before changing policy on any scoped account.

Map passkeys to framework outcomes, not compliance labels

A passkey is a FIDO2/WebAuthn public-key credential that signs a challenge for a specific website instead of transmitting a reusable password. A synced passkey is available across a user's devices through a sync service. A device-bound authenticator keeps the key on one authenticator. That difference matters for NIST's authentication assurance levels (AALs), which measure confidence in an authentication event.

NIST defines three tiers. AAL1 requires only single-factor authentication and permits a standard password. AAL2 and AAL3 are where passkey choice actually changes what you can claim.

Where a passkey supports AAL2

AAL2 requires two distinct authentication factors or a qualifying multi-factor authenticator, and applications must offer a phishing-resistant option. A passkey can support AAL2 when the deployment meets those conditions.

User verification matters here: a WebAuthn credential without user verification is single-factor cryptographic authentication, not automatic AAL2. For a synced passkey, AAL2 also requires the Appendix B safeguards and AAL2-equivalent MFA for access to the sync fabric.

Why synced passkeys cannot reach AAL3

AAL3 requires a phishing-resistant authenticator with a non-exportable key and two distinct factors. A device-bound, non-exportable authenticator is the relevant direction here. Syncing makes the authentication key exportable, so a synced authenticator cannot meet AAL3's non-exportability requirement, regardless of how well it performs at AAL2.

How passkeys affect the other frameworks

For ISO 27001, SOC 2, NIS2, DORA, HIPAA, and GDPR, passkeys can support secure authentication and reduce phishing exposure, but they don't replace access reviews, RBAC, recovery controls, logging, or vendor assurance. For PCI DSS, phishing-resistant authentication can affect which MFA requirement applies to a given access path, but it is not a blanket PCI exemption. Confirm the exact mapping with your assessor.

A passkey strengthens authentication, but compliance still depends on who can enroll it, how access is revoked, how recovery works, and what evidence you keep. A synced passkey on a low-risk internal tool and a device-bound passkey guarding a PCI-scoped administrator account satisfy very different policy requirements, even though both are called "passkeys."

Implement the Credential Governance Overlay

The CGO translates the standards map into five operational layers, each with its own action and evidence trail. A common audit problem is failing to show the credential lifecycle.

• Identity lifecycle. Connect the vault to an authoritative identity source. Approve access before issuance, adjust it on role change, and remove it at offboarding. A departing contractor's vault access should be revoked the day the contract ends, not the following payroll cycle. Retain approval and deprovisioning records.
• Authenticator policy. Separate single-factor, MFA, and phishing-resistant paths. Allow long generated passwords and autofill, screen new passwords for compromise, and apply a distinct policy for privileged and PCI-scoped accounts, such as an administrator account inside the CDE. Retain policy configurations and screening results.
• Vault access. Use individual accounts, least-privilege roles, segmented vaults, and time-bound third-party access. Retain access matrices, review records, and export or share events.
• Evidence and monitoring. Send credential-access events to a reviewable log or a security information and event management (SIEM) system. Review anomalies, exports, and role changes. Retain investigation records, not only raw logs.
• Resilience and privacy. Test vault recovery, backup, emergency access, and key-management procedures. Retain test results, recovery approvals, and risk decisions.

The strongest password manager audit record proves the lifecycle of a credential: approved, issued, used, reviewed, revoked, and recoverable under controlled conditions.

Turn controls into operating evidence with Passwork

A product should be evaluated against that evidence model, not against a compliance badge. Passwork's access-management controls can help operationalize several CGO layers, though no single tool satisfies a framework on its own: Active Directory (AD) and LDAP group-driven permissions, granular vault, folder, and password-level permissions, SAML single sign-on, two-factor authentication with YubiKey support, and audit logging for read, write, share, and export activity.

Mapped to the CGO: AD/LDAP integration and RBAC support identity lifecycle, and segmented vault permissions support least privilege. Audit logs support the evidence layer. The choice between self-hosted and cloud deployment supports data-residency decisions specific to your scope.

None of this makes an organization compliant by itself. It gives a security team the configuration and records to support that work, which still has to be mapped to the organization's own scope and policies.

Put these password manager compliance standards into practice

Password manager compliance in 2026 comes down to four moves: 

• Inventory your accounts and systems 
• Label which regulatory scope each falls under
• Map the Credential Governance Overlay to the strictest applicable control
• Test whether your evidence trail holds up under review 

These password manager compliance standards agree on outcomes, not on a single product requirement.

Use a password management program to turn credential policy into a control your security team can operate and your auditors can verify. Start with the account inventory this week, then read our guide on how to use a password manager for the next step.

Frequently asked questions