Compliance Framework Alignment
ISO/IEC 27001:2022 — A.5.17 (Authentication information) SOC 2 — CC6.1 (Logical access controls) PCI DSS v4.0.1 — Requirement 8 (8.3.x passwords; 8.4–8.5 MFA) NIST SP 800-63B-4 (Authentication & authenticator management) This standard is a configurable template mapped to the requirements of the listed frameworks; it is a starting point for your own controls and is not legal or certification advice.
ACME TECHNOLOGIES PVT LTD AUTHENTICATION & PASSWORD STANDARD
Effective Date [Effective Date]
Standard Owner CISO
Review Cycle annually
Card Data in Scope No 1. Purpose and Scope
This standard defines how Acme Technologies Pvt Ltd issues, protects and retires the authentication information used to verify the identity of every person, service and system that accesses its information assets. It applies to all employees, contractors, temporary staff and third parties, and to all accounts — interactive user accounts, privileged and administrative accounts, and non-interactive service and system accounts — across on-premise, cloud and hosted environments. It supports the requirements of ISO/IEC 27001:2022 Annex A control 5.17, SOC 2 Common Criteria CC6.1, PCI DSS v4.0.1 Requirement 8 and NIST SP 800-63B-4, and takes precedence over any conflicting local practice.
2. Authentication Information as Protected Data
Authentication information — including passwords, passphrases, PINs, cryptographic keys, one-time-passcode seeds, recovery codes and biometric templates — is classified as confidential and is protected in transit and at rest. It SHALL NOT be transmitted or stored in cleartext, hard-coded into source code, embedded in scripts or configuration files, written to logs, or shared between individuals. Initial and reset credentials are delivered over a channel separate from the account identifier, are unique and unpredictable, and expire if unused. Every material event in the lifecycle of authentication information — allocation, reset, revocation and privileged issuance — is recorded in a tamper-resistant log, as required by ISO/IEC 27001:2022 A.5.17.
3. Password Composition and Length
User-chosen passwords SHALL be a minimum of 12 characters and SHALL support at least 64 characters, the full printable character set, spaces and passphrases. In line with NIST SP 800-63B-4, the organisation does NOT impose arbitrary composition rules (such as mandatory mixes of character classes), does not use knowledge-based security questions as an authenticator, and does not truncate passwords or block paste, because these practices weaken rather than strengthen memorised secrets. Where a cardholder data environment is in scope, PCI DSS v4.0.1 Requirement 8.3.6 sets a floor of 12 characters containing both numeric and alphabetic characters; the length configured in this standard meets or exceeds that floor.
4. Screening Against Breached and Weak Passwords
When a password is created or changed, the verifier SHALL compare the candidate against a blocklist of values that are known to be commonly used, expected or compromised — including passwords drawn from prior breach corpuses, dictionary words, repetitive or sequential characters, and context-specific terms such as the service name or the username. Candidates that appear on the blocklist SHALL be rejected with guidance to choose a different value. This screening is the primary defence that replaces periodic expiry and composition rules under NIST SP 800-63B-4, and directly supports the strength objective of PCI DSS Requirement 8.3.
5. Password Rotation and Change
Consistent with NIST SP 800-63B-4, passwords SHALL NOT be forced to expire on a fixed calendar schedule. Credentials are changed only when there is evidence or reasonable suspicion of compromise, when they appear on a breach corpus, or on personnel or role change. When there is evidence of compromise, the affected credential SHALL be changed immediately and any active sessions terminated. If a cardholder data environment is later introduced, the 90-day PCI DSS rule must be applied to password-only accounts within that environment.
6. Credential Storage, Hashing and Reuse
Verifiers SHALL store memorised secrets only in a form resistant to offline attack: each password is salted with a unique value of at least 32 bits and hashed using an approved, deliberately slow one-way key derivation function such as PBKDF2, Balloon, scrypt or Argon2, preferring a memory-hard function to raise the cost of guessing. Reversible encryption and unsalted or fast general-purpose hashes (for example plain MD5 or SHA-256) SHALL NOT be used for password storage. First-use and reset passwords are set to a unique value and forced to change on first use, in line with PCI DSS v4.0.1 Requirement 8.3.5. Where a cardholder data environment is in scope, Requirement 8.3.7 additionally prohibits reuse of any of the previous four passwords.
7. Multi-Factor Authentication
Multi-factor authentication SHALL be enforced for all privileged, administrative and remote access, combining at least two independent factors from separate categories (something you know, something you have, something you are). Phishing-resistant authenticators — such as FIDO2/WebAuthn security keys or passkeys, or PKI-based smart cards — are the preferred and default method, consistent with NIST SP 800-63B-4, under which a phishing-resistant option is offered at AAL2 and required at AAL3. MFA prompts SHALL be resistant to replay, and push-based methods SHALL be protected against fatigue and prompt-bombing through number matching or equivalent. Where a cardholder data environment is in scope, PCI DSS v4.0.1 Requirements 8.4.1, 8.4.2 and 8.4.3 mandate MFA for all administrative and all remote and internal access into the CDE, and Requirement 8.5 requires the MFA implementation to be resistant to replay and not bypassable.
8. Account Lockout and Anti-Automation
To resist online guessing, verifiers SHALL limit consecutive failed authentication attempts. In line with PCI DSS v4.0.1 Requirement 8.3.4, an account SHALL be locked after no more than 10 invalid attempts and SHALL remain locked for at least 30 minutes or until the user's identity is verified and the account is deliberately reset. Rate limiting, progressive delays, CAPTCHA or equivalent anti-automation controls are applied to authentication and reset endpoints, and repeated lockouts or credential-stuffing patterns are alerted to the security team for investigation.
9. Session Management and Timeout
Authenticated sessions SHALL be bound to the authenticated identity, protected with unpredictable session identifiers and secure, HTTP-only cookies over TLS, and re-established through a fresh authentication event rather than by reusing old credentials. Idle sessions SHALL be terminated after 15 minutes of inactivity, requiring re-authentication to resume; consoles and administrative sessions use the same or a shorter limit. Re-authentication SHALL be required for sensitive operations such as changing authentication information or elevating privileges, and logout SHALL fully invalidate the session on the server side.
10. Service, System and Machine Accounts
Non-interactive service, system and application accounts SHALL be individually identifiable, owned by a named individual or team, and used only for their intended purpose. Their authentication factors — passwords, API keys, tokens and certificates — SHALL be unique, of high entropy, stored in a managed secrets vault rather than in code or configuration, and rotated on a defined schedule and immediately on suspected compromise or on departure of anyone who held them. Interactive login for such accounts SHALL be disabled where technically possible, and their use SHALL be logged and reviewed. This reflects the strict management of application and system accounts required by PCI DSS v4.0.1 Requirement 8.6, including the controlled handling of any hard-to-avoid interactive use (8.6.1) and of passwords used by such accounts (8.6.3).
11. Account Provisioning, Reset and Deprovisioning
User identity is verified before authentication information is issued, and access is granted on a least-privilege, need-to-know basis. Self-service and helpdesk password resets SHALL verify the requester's identity to a level appropriate to the account's sensitivity before a credential is changed, and reset events are logged. Accounts SHALL be disabled promptly on termination or role change and reviewed at defined intervals; dormant, orphaned, generic and default accounts are identified and removed, and vendor-supplied default credentials SHALL be changed before a system is placed into service.
12. User Responsibilities
Individuals SHALL choose unique credentials that are not reused across the organisation's systems and personal services, SHALL protect authentication information from disclosure, and SHALL NOT share accounts or credentials. The organisation provides and encourages an approved password manager to support the use of long, unique passwords. Suspected compromise, loss of an authenticator, or phishing of credentials SHALL be reported to the security team without delay so that the affected credentials can be revoked and re-issued.
13. Monitoring, Logging and Review
Authentication events — successful and failed logins, lockouts, MFA challenges, privileged access and credential changes — SHALL be logged, protected from tampering, retained in line with the organisation's records requirements, and monitored for anomalies. These logs provide the evidence of enforcement expected under SOC 2 CC6.1 and PCI DSS Requirement 8, and support the record-keeping obligation of ISO/IEC 27001:2022 A.5.17.
14. Exceptions, Ownership and Review
Any deviation from this standard SHALL be documented, risk-assessed, time-bound and approved in writing by the standard owner, with compensating controls recorded. This standard is owned by CISO and is reviewed at least annually and after any significant incident, technology change or change in the applicable frameworks. Non-compliance may result in withdrawal of access and disciplinary or contractual action.
Control area Requirement in this standard Primary mapping Password length Minimum 12 characters; up to 64+ supported PCI DSS 8.3.6; NIST 800-63B Breach screening Screen candidates against known-compromised and weak-password blocklist NIST 800-63B Rotation No arbitrary expiry; change on evidence of compromise PCI DSS 8.3.9; NIST 800-63B Credential storage Salted (>=32-bit) and hashed with an approved slow KDF NIST 800-63B; ISO 27001 A.5.17 Multi-factor authentication Enforced for all privileged, administrative and remote access; phishing-resistant preferred PCI DSS 8.4-8.5; NIST 800-63B Account lockout Lock after <=10 failed attempts for >=30 minutes PCI DSS 8.3.4 Session timeout Idle sessions end after 15 minutes SOC 2 CC6.1 Service/system accounts Vaulted, unique, rotated, owned and logged PCI DSS 8.6; ISO 27001 A.5.17
Approved by
Head of Information Security
______________________