ISO 27001 A.5.17: Authentication Information

Quick Reference (60 Seconds)

ISO 27001:2022 Annex A 5.17 asks for the allocation and management of authentication information to be controlled by a management process, including advising personnel on how to handle it.

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 Control Asks For

The Control in Brief

In short:

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

Do you need this control?

A.5.17 is not mandatory in itself: under clause 6.1.3 you include it if your risk assessment calls for it, and record the decision in your Statement of Applicability. Include it wherever passwords, keys, tokens or other authentication secrets are issued, which is almost everyone. You can adapt it toward passwordless or MFA-first approaches; the control is about managing authentication information, whatever form it takes.

What ISO 27002:2022 Adds

ISO/IEC 27002 guidance for 5.17 (paraphrased):

Allocating authentication information

• temporary passwords or PINs issued at enrolment are unique, hard to guess and must be changed at first use
• the user's identity is verified before new, replacement or temporary credentials are issued
• credentials are delivered over a secure channel, never in clear-text email
• users acknowledge receipt
• vendor default credentials are changed immediately after installation
• significant events in allocating and managing credentials are recorded, confidentially, using an approved method such as a password vault

User responsibilities (also written into terms of employment, A.6.2)

• keep secret authentication information confidential; never share personal credentials; share credentials of shared or non-personal identities only with authorised people
• change credentials immediately if they may be compromised
• choose strong passwords: not based on personal details or dictionary words, easy-to-remember passphrases, a minimum length
• do not reuse the same password across services

Password management systems should let users choose and change their own passwords (with a confirmation step), enforce strong passwords, force a change at first login and when needed (after an incident, or when someone who knew a shared password leaves), prevent reuse and the use of common or breached passwords, hide passwords as they are typed, and store and transmit them in protected form using approved techniques (A.8.24).

27002 also notes that frequent forced password changes can be counter-productive: users pick weak variations or write passwords down. MFA, passwordless methods and credential rotation are covered by A.8.5 (secure authentication) and your risk assessment rather than by 5.17 itself.

What Auditors Usually Look For

None of these is mandated by ISO; they are what auditors typically ask to see for A.5.17.

Why Authentication Information Matters

Credential Compromise Statistics

Password Policy Design

Password Policy Requirements by Role

ISO 27001 sets no password values. The table follows NIST SP 800-63B (Rev. 4) and 27002's warning about frequent forced changes.

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

IP allow-lists, geo-restriction and zero-trust architecture are network or policy controls that complement authentication; they do not authenticate the caller.

Service Account Authentication

Service Account Authentication Best Practices

Authentication Monitoring and Analytics

Authentication Monitoring Requirements

SIEM Rules for Authentication

Illustrative SPL; adapt index and field names to your data. Distance is calculated with the haversine formula in eval.

## Splunk: Detect impossible travel (successive logins faster than ~900 km/h)
index=authentication action=success earliest=-24h
| iplocation src_ip
| sort 0 user _time
| streamstats current=f last(lat) as prev_lat last(lon) as prev_lon last(_time) as prev_time by user
| where isnotnull(prev_lat)
| eval rlat1=prev_lat*pi()/180, rlat2=lat*pi()/180, dlat=rlat2-rlat1, dlon=(lon-prev_lon)*pi()/180
| eval a=pow(sin(dlat/2),2)+cos(rlat1)*cos(rlat2)*pow(sin(dlon/2),2)
| eval distance_km=6371*2*atan2(sqrt(a), sqrt(1-a)), hours=(_time-prev_time)/3600
| where hours>0 AND distance_km/hours > 900

## Splunk: Detect brute force (more than 5 failures in 5 minutes)
index=authentication action=failure earliest=-5m
| stats count by user, src_ip
| where count > 5

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

## Splunk: Detect credential stuffing (many users tried from one IP)
index=authentication action=failure earliest=-15m
| 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 Microsoft Entra ID
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: The bank's risk assessment rated SMS OTP too weak for staff access to core systems (SIM-swap risk), and service account passwords lived in spreadsheets
Solution:

1. Replaced SMS OTP with hardware tokens (YubiKey 5 NFC) for all employees
2. Issued device-bound FIDO2 keys with PIN for high-risk roles (admins, 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 accounts with FIDO2 keys held in a safe and alerting on use
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: A.5.17 is about managing authentication information; MFA requirements come from A.8.5 and your risk assessment. In practice auditors expect MFA for privileged, remote and internet-facing access, and MFA for all users is now normal good practice.

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, rely on consent or (for employees) DPDP s.7(i) legitimate use, allow deletion, and assess the risk; a formal DPIA is mandatory only for Significant Data Fiduciaries under DPDP and where GDPR applies.

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: User and admin passwords: no periodic expiry; change them on any sign of compromise (27002 warns that frequent forced changes backfire, and NIST SP 800-63B agrees). 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).

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 review their access quarterly (see A.5.18). 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. Adaptive authentication itself belongs to A.8.5 (secure authentication); A.5.17 covers managing the credentials and factors it relies on.

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 Expectations for Authentication Information (practice under the 2016 Cyber Security Framework and the 2023 IT Governance Master Direction; not prescribed values)

SEBI and IRDAI Authentication Requirements

Continuous Improvement

Figure · Tiers

Maturity levels for authentication information

Authentication Information Maturity Model

Annual Improvement Agenda

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. NIST published the first post-quantum standards (FIPS 203, 204 and 205) in August 2024; organizations should: track vendor support for them, 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 (composite)

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 placed on compromised accounts
• Customer data access (addresses, partial card numbers, order history)
• CERT-In report within 6 hours; DPDP Board and customer notification once the Rules' breach duties apply
• Card networks and the payment aggregator notified under their contracts
• Customer churn in the affected segment
• Remediation effort: 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 (composite)

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 effort: 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)

Relationship to Other Controls

References

• ISO/IEC 27001:2022, Annex A 5.17; ISO/IEC 27002:2022, 5.17 (consulted, paraphrased)
• NIST SP 800-63B (Digital Identity Guidelines: Authentication and Lifecycle Management)
• NIST SP 800-53 Rev. 5, IA-5
• OWASP Password Storage Cheat Sheet
• CA/Browser Forum Ballot SC-081 (certificate validity reduction)
• NIST FIPS 203, 204 and 205 (post-quantum cryptography, 2024)
• Verizon Data Breach Investigations Report 2025; UK NCSC breached-password analysis (2019)

Document Control

• Version: 1.1
• Review Cycle: Annual + event-triggered
• Next Review: June 2027