ISO 27001 A.5.17: Authentication Information

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.17 requires the allocation and management of authentication information to be controlled through a formal process, ensuring that credentials are created, distributed, and stored securely.

The Bottom Line: Authentication information is the keys to your kingdom. If you don't protect how credentials are created, stored, and used, nothing else matters.

What the Standard Actually Requires

The ISO 27001:2022 Text

Annex A 5.17 states:

ISO 27001:2022 Annex A 5.17 asks organizations to control the allocation and management of authentication information through a formal process.

What ISO 27002:2022 Adds

The implementation guidance requires:

• Authentication information (credentials) created securely
• Credentials distributed securely to users
• Users required to sign acknowledgment of receipt
• Users required to change initial/temporary passwords
• Credentials stored securely (hashed, encrypted, vaulted)
• Credentials not shared, not written down, not stored in plaintext
• Regular credential rotation
• Compromised credentials revoked immediately
• Credential recovery process secure and audited
• MFA for sensitive access
• Password policy enforced
• Passwordless authentication considered

The Six Mandatory Components

Why Authentication Information Matters

Credential Compromise Statistics

Password Policy Design

Password Policy Requirements by Role

Password Policy Best Practices

Password Storage and Hashing

Password Hashing Algorithms

Hashing Implementation

Credential Storage Best Practices

Password Reset and Recovery

Secure Password Reset Process

Password Reset Security Requirements

Multi-Factor Authentication (MFA)

MFA Factor Types

MFA Implementation by Risk Level

Passwordless Authentication

Passwordless Methods

Passwordless Implementation Roadmap

Biometric Authentication

Biometric Methods

Biometric Storage and Privacy

Certificate-Based Authentication

Certificate Types

Certificate Lifecycle Management

Token-Based Authentication

Token Types

API Authentication

API Authentication Methods

Service Account Authentication

Service Account Authentication Best Practices

Authentication Monitoring and Analytics

Authentication Monitoring Requirements

SIEM Rules for Authentication

## Splunk: Detect impossible travel
index=authentication
| eval time_diff=abs(now()-_time)
| stats values(src_ip) as src_ips, values(src_geo) as locations, min(_time) as first_login, max(_time) as last_login by user
| eval travel_time=last_login-first_login
| eval max_possible_distance=travel_time*1000
| eval actual_distance=... (geo distance calculation)
| where actual_distance > max_possible_distance

## Splunk: Detect brute force
index=authentication action=failure
| stats count by user, src_ip
| where count > 5
| eval time_window=5
| where _time > relative_time(now(), "-5m")

## Splunk: Detect off-hours admin login
index=authentication action=success user_role=admin
| eval hour=strftime(_time, "%H")
| where hour < 6 OR hour > 22
| stats count by user, src_ip, hour
| where count > 0

## Splunk: Detect credential stuffing
index=authentication action=failure
| stats dc(user) as user_count, count as attempt_count by src_ip
| where user_count > 10 AND attempt_count > 20

Tool Comparison

Implementation Roadmap: 4 Weeks

Common Audit Failures and Fixes

Illustrative Scenarios

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: SaaS Company Implements Passwordless for 800 Users

Company: 800-employee SaaS, weak passwords, no MFA, frequent credential stuffing attacks
Challenge: Credential stuffing attacks, weak passwords, no MFA, audit finding on A.5.17
Solution:

1. Implemented strong password policy with HIBP compromised check
2. Deployed MFA for all users (TOTP app + push notification)
3. Deployed YubiKey FIDO2 keys for all 50+ admin accounts
4. Implemented passwordless (FIDO2 + passkeys) for all users via Azure AD
5. Deployed HashiCorp Vault for 200+ service accounts with automated rotation
6. Implemented self-service password reset with MFA verification
7. Deployed SIEM rules for authentication monitoring (50+ rules)
8. Implemented certificate-based authentication for service-to-service APIs
9. Trained all users on passwordless and passkey usage
10. Implemented break-glass procedure with pre-approved emergency accounts

Outcome: 100% MFA enrollment. 85% passwordless adoption within 6 months. Credential stuffing attacks reduced by 95%. Service account credentials never hardcoded. Authentication incidents reduced by 90%. Passed ISO 27001 audit with zero findings on A.5.17.

Illustrative Scenario 2: Bank Implements Hardware MFA and Vault for 2,000 Employees

Company: 2,000-employee bank, SMS OTP for MFA, no hardware keys, service accounts in spreadsheets
Challenge: RBI requirement for strong MFA, SMS OTP not sufficient for banking, no credential vault
Solution:

1. Replaced SMS OTP with hardware tokens (YubiKey 5 NFC) for all employees
2. Implemented biometric + hardware key for high-risk roles (CISO, admin, finance)
3. Deployed CyberArk for PAM and credential vault (500+ service accounts)
4. Implemented automated rotation for all service accounts (90 days)
5. Implemented certificate-based authentication for all internal APIs
6. Implemented passwordless for customer-facing applications (FIDO2 + passkeys)
7. Deployed SIEM with 100+ authentication monitoring rules
8. Implemented adaptive authentication (risk-based step-up MFA)
9. Implemented break-glass with dual control and HSM-backed keys
10. Trained all employees on hardware key usage and security

Outcome: 100% hardware MFA adoption. Zero SMS OTP usage. 500+ service accounts in vault with automated rotation. API authentication fully certificate-based. Authentication incidents reduced by 88%. RBI audit passed with no findings. Customer authentication fraud reduced by 75%.

Multi-Framework Mapping

FAQ

Q: Does A.5.17 require MFA for all users or just privileged users?
A: MFA is required for all privileged access. For standard users, MFA is highly recommended and considered best practice. The standard requires strong authentication for sensitive access at minimum.

Q: What is the best password hashing algorithm?
A: Argon2id is the current best practice (OWASP recommendation). bcrypt is also excellent and widely supported. scrypt is good for memory-hard requirements. PBKDF2 is acceptable with high iteration counts. Never use MD5, SHA-1, or SHA-256 for password hashing.

Q: Can we store passwords in plaintext for any reason?
A: No. Never store plaintext passwords. Always hash passwords with a strong algorithm (Argon2id, bcrypt). If you need to verify passwords (e.g., for integration), use a secure vault or delegated authentication.

Q: Does A.5.17 require passwordless authentication?
A: Not required, but highly recommended. Passwordless (FIDO2, passkeys, Windows Hello) is stronger than passwords and is acceptable for ISO 27001. Many auditors view passwordless as a sign of mature security.

Q: How do we handle legacy systems that don't support modern authentication?
A: Use PAM for legacy system access, implement MFA at the gateway level, use VPN with MFA for remote access, and plan migration. Document the compensating controls and migration plan.

Q: What is the minimum evidence for A.5.17?
A: Password policy, hashing algorithm documentation, MFA enrollment records, credential vault records, rotation logs, authentication monitoring logs, and passwordless implementation records (if applicable).

Q: Can we use SMS OTP for MFA?
A: SMS OTP is acceptable for low-risk access but is not recommended for high-risk or privileged access due to SIM swapping and interception risks. Use TOTP apps, push notifications, or hardware keys for better security.

Q: How do we handle biometric data privacy?
A: Store templates (not raw images), encrypt, separate from other data, obtain consent, allow deletion, and conduct a DPIA. Follow DPDP Act and GDPR requirements for biometric data.

Q: Does A.5.17 require certificate-based authentication?
A: Not required for all users, but certificate-based auth is recommended for high-security environments, service-to-service communication, and admin access. At minimum, use certificates for API and service account authentication.

Q: How often should we rotate passwords?
A: For user passwords with MFA: never (or 180 days). For admin passwords: 90 days (or never if hardware MFA). For service accounts: 90 days or automated rotation. For API keys: 90 days or automated rotation. For certificates: per validity period (typically 1-2 years).

Need help? Contact us for a 20-minute readiness call.

Q: What is the difference between A.5.17 and A.8.5? A: A.5.17 covers the lifecycle of authentication information (creation, distribution, storage, rotation, revocation). A.8.5 covers the actual authentication process (how users prove their identity). A.5.17 is the "key management" while A.8.5 is the "door lock." Both are required for complete authentication security.

Q: How do we handle authentication information for third-party contractors? A: Create dedicated accounts with time-bound access, enforce MFA, use conditional access (location, time), monitor all activity, revoke immediately upon contract end, and conduct access reviews monthly. Never share internal employee credentials with contractors.

Q: What is a credential vault and why do we need one? A: A credential vault (HashiCorp Vault, CyberArk, Azure Key Vault, AWS Secrets Manager) is a secure system for storing and managing credentials. It provides encryption, access controls, rotation, audit logging, and API access. Essential for service accounts, API keys, and shared credentials. Without a vault, credentials are often hardcoded in code or stored in spreadsheets.

Q: How do we handle authentication information during mergers and acquisitions? A: Integrate identity systems, harmonize password policies, migrate credentials to the acquiring organization's vault, conduct access reviews for all inherited accounts, revoke redundant accounts, and ensure consistent MFA enforcement across the merged entity.

Q: What is adaptive authentication and how does it relate to A.5.17? A: Adaptive authentication adjusts authentication strength based on risk signals (location, device, behavior, time). It requires dynamic credential management, different credentials or factors for different risk levels. This is part of A.5.17 because it involves managing multiple authentication factors and their deployment based on risk.

Q: How do we handle authentication information for IoT devices? A: IoT devices should use certificates (X.509) or TPM-based authentication, not passwords. Use device-specific credentials, store in vault, rotate via automated processes, and monitor for anomalous authentication. Never use default passwords on IoT devices.

Q: What is the role of A.5.17 in Zero Trust architecture? A: Zero Trust requires strong, verifiable authentication for every access request. A.5.17 ensures the credentials used in Zero Trust are properly managed, rotated, and protected. Without proper credential management, Zero Trust cannot function securely.

Indian Regulatory Context

DPDP Act 2023 and Authentication Information

RBI Guidelines for Authentication Information

SEBI and IRDAI Authentication Requirements

Continuous Improvement

Authentication Information Maturity Model

Annual Improvement Agenda

Need help? Contact us for a 20-minute readiness call.

Q: How do we handle authentication information for DevOps pipelines? A: DevOps pipelines require service accounts, API keys, and deployment credentials. Use dedicated CI/CD service accounts, store credentials in vault with short-lived tokens, implement OIDC for cloud deployments, rotate pipeline credentials automatically, and audit all pipeline access. Never store credentials in pipeline configuration files or environment variables in plain text.

Q: What is the role of A.5.17 in cloud security? A: Cloud environments rely heavily on API keys, service principals, and IAM roles. A.5.17 ensures these credentials are properly managed: cloud provider API keys stored in vault, IAM roles scoped with least privilege, cross-account roles reviewed quarterly, and cloud credentials rotated per provider best practices (AWS: 90 days, Azure: 1 year for SP secrets, GCP: 90 days for service account keys).

Q: How do we handle authentication information for disaster recovery? A: DR systems need authentication credentials that work independently of primary systems. Store DR credentials in a separate vault, ensure DR credentials are not dependent on primary infrastructure (e.g., don't store DR vault credentials in primary AD), test DR authentication quarterly, and document DR credential recovery procedures.

Q: What is the impact of quantum computing on authentication information? A: Quantum computing threatens current asymmetric encryption (RSA, ECC) used in certificates and key exchange. While quantum-safe algorithms are still being standardized, organizations should: monitor NIST post-quantum cryptography standards, plan for certificate algorithm migration (RSA → lattice-based), and ensure crypto-agility (ability to switch algorithms quickly).

Additional Illustrative Scenarios: Indian Authentication Incidents

Illustrative Scenario 3: Indian E-commerce, Credential Stuffing Attack (2023)

What happened: An Indian e-commerce platform with 5 million users suffered a credential stuffing attack. Attackers used 2 million leaked credentials from other breaches to attempt logins. The platform had no MFA, no breach detection, and no rate limiting. 15,000 accounts were compromised.

Impact:

• 15,000 customer accounts compromised
• Fraudulent orders:
• Customer data access (addresses, partial card numbers, order history)
• DPDP Act 2023 notification required
• RBI notification for payment data exposure
• Customer churn: 8% in affected segment
• Remediation overhead: (MFA deployment, incident response, customer communication, legal)

Root causes:

• No MFA on customer accounts
• No credential breach detection (Have I Been Pwned integration)
• No rate limiting on login endpoints
• No account takeover detection
• No monitoring for impossible travel or anomalous login patterns
• Weak password policy (8 characters, no breach detection)

Lessons:

• Implement MFA on all accounts (customer + employee)
• Integrate breach detection (Have I Been Pwned API, SpyCloud)
• Implement rate limiting (5 attempts per 15 minutes, CAPTCHA after 3 failures)
• Deploy account takeover detection (UEBA, impossible travel, new device alerts)
• Implement progressive authentication (stronger auth for sensitive actions)
• Monitor for credential stuffing patterns (same password across multiple accounts)
• Force password reset for breached credentials

Illustrative Scenario 4: Indian Government Portal, Default Admin Credentials (2022)

What happened: A state government portal for citizen services was found to have default admin credentials (admin/admin123) on the administrative backend. The portal had been live for 2 years without changing defaults. A security researcher discovered and responsibly disclosed the issue.

Impact:

• 2 years of potential unauthorized admin access
• 500,000+ citizen records potentially accessible
• Portal taken offline for 3 weeks for security remediation
• CERT-In notification required
• Reputational damage for government digital initiatives
• Remediation overhead: (security audit, penetration testing, new authentication system, monitoring)

Root causes:

• Default credentials never changed after deployment
• No initial security configuration review
• No periodic authentication review
• No penetration testing before launch or annually
• No security awareness among deployment team
• No change management process for security configurations

Lessons:

• Change all default credentials before deployment (Day 1 checklist)
• Conduct security configuration review before go-live
• Implement annual penetration testing for all internet-facing systems
• Deploy automated scanning for default credentials (Nessus, OpenVAS)
• Include authentication security in change management process
• Train deployment teams on security baselines
• Implement break-glass admin accounts with MFA only (no default passwords)

Need help? Contact us for a 20-minute readiness call.