Most organizations treat authentication as a solved problem. They enforce password complexity, maybe roll out Multi-Factor Authentication (MFA) on a few systems, and move on. But credentials don’t just need to be strong. They need to be managed across their entire lifecycle, from the moment they’re issued to the moment an employee walks out the door. ISO 27001 5.17 exists because that lifecycle is where most access control frameworks quietly fall apart.
What 5.17 requires
ISO 27001 Control 5.17 requires organizations to establish a formal management process for all authentication information. That means passwords, PINs, hardware tokens, biometric enrollment data, and cryptographic keys all fall under the same governance umbrella.
The control’s requirements break down into five operational obligations:
- Identity verification before issuance: Every credential allocation or reset must include a step that confirms the requester is who they claim to be. This applies to help desk resets, self-service portals, and automated provisioning workflows.
- Secure transmission: Authentication information must never travel over plaintext channels. Email, unencrypted chat, and shared documents are explicitly out of scope as delivery mechanisms.
- User handling obligations: Users must acknowledge that credentials are not to be shared, must be changed immediately upon suspected compromise, and must not be reused across systems.
- Default credential replacement: Every vendor-supplied default password, token, or key must be changed before a system enters production. This includes network devices, SaaS platforms, and infrastructure appliances.
- Credential lifecycle management: Organizations need documented procedures for provisioning, rotating, and revoking credentials tied to employment status changes, role transitions, and system decommissioning.
The control objective isn’t just about password strength. It’s about ensuring that every credential issued by the organization has a known owner, a defined purpose, a secure delivery path, and a revocation trigger. Without that managed process, authentication information becomes the weakest link regardless of how sophisticated the rest of the security program is.
This is what distinguishes ISO 27001 Annex A 5.17 from a basic password policy. Most organizations already enforce complexity rules and lockout thresholds. Far fewer have documented procedures for how credentials are allocated to new employees, how they’re transmitted securely during onboarding, how identity is verified before a help desk reset, or what triggers automatic revocation when someone leaves. Control 5.17 treats authentication information as an asset requiring full lifecycle governance, not just a technical configuration to set and forget.
Why 5.17 matters
A midsize financial services firm passes its annual audit with clean findings. Access controls are documented, role-based permissions are in place, and MFA is deployed for VPN access. Six months later, a former contractor’s credentials are used to access an internal reporting system. The account was never deprovisioned because the offboarding process didn’t include a credential revocation checklist tied to the identity provider. The breach goes undetected for weeks.
This is the gap 5.17 addresses. Organizations can have robust access control policies and still leave themselves exposed if authentication information isn’t actively managed across its lifecycle. Credential compromise remains the dominant initial access vector in data breaches. According to the Verizon 2025 Data Breach Investigations Report, use of stolen credentials accounted for 22% of breaches. That statistic reflects a systemic problem: credentials are issued, forgotten about, and exploited long after they should have been revoked.
The risk compounds because a single compromised credential rarely stays contained. An attacker with valid credentials can move laterally, escalate privileges, and establish persistence without triggering the alerts that anomalous behavior would. For organizations pursuing or maintaining ISO 27001 certification, a nonconformity against 5.17 signals a foundational weakness in identity and access management.
What attackers exploit
When authentication information controls fail, attackers target predictable weaknesses:
- Default credentials left unchanged on production systems, network devices, and SaaS platforms
- Shared service accounts with no individual accountability or audit trail
- Passwords stored in plaintext in spreadsheets, internal wikis, or code repositories
- Credential resets performed without identity verification, enabling social engineering against help desks
- Password reuse across personal and corporate accounts, allowing credential stuffing from public breaches
- Stale credentials for departed employees, contractors, or decommissioned systems
- Absence of MFA on privileged or remote access paths
Each of these represents a failure mode that 5.17 is specifically designed to prevent through documented procedures and technical controls. Attackers don’t need to find a zero-day when a valid credential is sitting in a public repository or an ex-employee’s account is still active in the identity provider.
How to implement 5.17
Implementation splits into two domains: controls you enforce within your own organization and assurance you require from your vendors.
For your organization
Start with the policy foundation and work outward to technical enforcement and operational procedures.
1. Document an authentication information policy. The policy should define every credential type in scope (passwords, tokens, biometric data, cryptographic keys), specify creation and complexity rules, describe secure distribution procedures, and identify revocation triggers. This is the artifact auditors will request first.
2. Deploy a centralized identity provider. Consolidate authentication through a Single Sign-On (SSO) and MFA platform. Identity providers such as Okta, Microsoft Entra ID, or JumpCloud centralize credential governance and create a single enforcement point for authentication policies across all connected applications.
3. Enforce technical password controls. Configure minimum length requirements, complexity rules, and breach-list checking against databases like the NIST SP 800-63B recommended approach of screening passwords against known compromised credential lists. Prohibit credential reuse across systems.
4. Mandate MFA for all remote access, privileged accounts, and cloud services. MFA should not be optional for any system accessible outside the corporate network or for any account with elevated permissions.
5. Establish identity verification procedures for credential resets. Build a help desk playbook that requires verifiable identity confirmation before any reset. This closes the social engineering vector that bypasses every other technical control.
6. Automate credential lifecycle events. Tie provisioning to HR onboarding workflows and revocation to offboarding. When an employee’s status changes in the Human Resources Information System (HRIS), credential state should change automatically.
7. Replace default vendor credentials during deployment. Add default credential remediation as a mandatory step in system deployment checklists with documented sign-off.
8. Conduct periodic access reviews. Review privileged account access at least quarterly. Non-privileged access should be reviewed at minimum annually, with account owners providing documented sign-off.
9. Train users on credential handling obligations. Security awareness training should include a module specifically covering credential handling, with documented completion records.
Organizations commonly undermine their own implementation by treating password policy as the entire control while ignoring allocation, secure transmission, and revocation procedures. Relying on periodic password rotation instead of breach-based rotation creates a false sense of security while frustrating users. Failing to verify identity before help desk resets leaves the front door open to social engineering. Leaving service account credentials embedded in code repositories introduces risk that no password policy can address. And without a formal process for revoking credentials when employees leave, every departure creates a potential access window.
For your vendors
Third-party vendors handling your data or accessing your systems need to demonstrate their own authentication information controls. This is a gap most organizations overlook during vendor assessments.
Security questionnaire questions to include:
- “Describe your credential lifecycle management process from provisioning through revocation.”
- “Is MFA enforced for all user access to systems processing our data?”
- “How are default credentials handled during system and application deployment?”
Evidence to request:
- Authentication information policy document
- MFA enrollment rates across the user population
- Password policy configuration exports from their identity provider
- Access review logs showing timely revocation
Red flags during assessment:
- Shared administrator accounts with no individual accountability
- No documented credential reset procedure
- Credentials transmitted via email or other unencrypted channels
- No MFA for remote access
- Inability to provide access review evidence
Go beyond self-attestation. Request penetration test reports and examine findings related to credential management. Review SOC 2 Type II reports for access control exceptions, paying particular attention to whether the auditor noted any deviations in logical access controls or user provisioning and deprovisioning procedures. Vendors that can’t demonstrate controlled authentication information management represent a supply chain risk that directly undermines your own 5.17 compliance posture. During ongoing monitoring, periodically re-request MFA enrollment rates and access review logs to confirm that controls remain effective, not just that they were present at the time of initial assessment.
Audit evidence for 5.17
Auditors assessing ISO 27001 5.17 expect documented evidence across the full credential lifecycle. Prepare the following artifacts before your audit:
| Evidence type | Example artifact |
|---|---|
| Policy | Authentication information policy defining credential types, complexity requirements, lifecycle procedures, and user obligations |
| Technical configuration | Password policy settings exported from Active Directory or identity provider showing enforced length, complexity, and lockout rules |
| MFA enrollment | Identity provider report showing MFA activation percentage across the user population |
| Credential issuance records | Ticketing system logs showing identity verification steps completed before credential resets |
| Access review logs | Quarterly privileged access review records with sign-off from account owners |
| Default credential remediation | System deployment checklist with sign-off confirming default credentials were changed |
| User acknowledgment | Signed acceptable use agreements confirming users understand credential handling obligations |
| Training records | Security awareness training completion records covering the credential handling module |
The strongest audit posture combines policy documentation with technical evidence showing those policies are enforced. An authentication information policy without matching identity provider configuration exports is a gap auditors will flag. Similarly, claiming quarterly access reviews without producing sign-off records leaves the auditor with no basis to confirm the control is operating effectively.
Organize evidence by control objective rather than by system. An auditor reviewing 5.17 wants to trace the credential lifecycle from issuance to revocation across multiple artifacts, not navigate a folder structure organized by tool name. Map each evidence artifact to the specific ISO 27001 5.17 requirement it satisfies so the auditor can verify coverage without requesting additional documentation.
Cross-framework mapping
Organizations operating under multiple compliance frameworks can map ISO 27001 5.17 controls to equivalent requirements, reducing duplicate assessment effort.
| Framework | Equivalent control(s) | Coverage |
|---|---|---|
| NIST 800-53 | IA-05 (Authenticator Management) | Full |
| NIST CSF 2.0 | PR.AA-03 (Users, services, and hardware are authenticated) | Full |
| SOC 2 | CC6.1 (Logical and Physical Access Controls) | Partial |
| CIS Controls v8.1 | 5.2 (Use Unique Passwords), 6.3 (Require MFA for Externally-Exposed Applications), 6.4 (Require MFA for Remote Network Access) | Partial |
| DORA (EU) | Article 9(4)(b) (Strong authentication mechanisms) | Partial |
The NIST 800-53 IA-05 mapping is the most direct equivalent, covering authenticator lifecycle management with nearly identical scope. SOC 2 and CIS Controls address overlapping requirements but distribute them across multiple controls, so partial coverage should be expected when mapping evidence between frameworks.
Related ISO 27001 controls
Control 5.17 operates within a cluster of identity and access management controls. Understanding these relationships helps organizations avoid implementing authentication information management in isolation.
| Control ID | Control name | Relationship |
|---|---|---|
| 5.15 | Access control | Defines the access policy that authentication enforces |
| 5.16 | Identity management | Provides the identities that 5.17 authenticates |
| 5.18 | Access rights | Manages the permissions tied to authenticated identities |
| 8.5 | Secure authentication | Technical implementation of authentication mechanisms |
| 5.10 | Acceptable use of information | Includes user obligations for credential handling |
| 8.2 | Privileged access rights | Elevated credentials requiring stricter 5.17 controls |
| 5.3 | Segregation of duties | Prevents single-credential compromise from enabling fraud |
| 6.1 | Screening | Pre-employment checks before granting authentication credentials |
| 6.5 | Responsibilities after termination | Credential revocation upon departure |
The most critical dependency is the chain from 5.16 (identity management) through 5.17 (authentication information) to 5.18 (access rights). A weakness in any link undermines the others. When planning implementation, address these controls as an integrated cluster rather than independently. Organizations that implement 5.17 in isolation often discover gaps at the boundaries, particularly around termination procedures (6.5) that should trigger credential revocation and privileged access management (8.2) that requires stricter authentication information controls than standard user accounts.
Frequently asked questions
What is ISO 27001 5.17?
ISO 27001 5.17 is an organizational control that requires a formal management process for allocating, safeguarding, and revoking authentication credentials such as passwords, tokens, and biometric data. It covers the entire credential lifecycle from initial issuance through ongoing use to revocation, ensuring that only verified individuals access organizational systems.
What happens if 5.17 is not implemented?
Without 5.17, organizations lack a controlled process for managing credentials, leaving them vulnerable to credential-based attacks including password spraying, social engineering of help desks, and unauthorized access through stale accounts. Auditors will raise a nonconformity, and the organization may face certification delays or suspension.
How do you audit 5.17?
Auditors verify 5.17 by reviewing the authentication information policy, testing credential reset procedures for identity verification, checking MFA enrollment rates, and examining access review logs for timely revocation. They may also perform desk checks to confirm users are not storing credentials insecurely.
How UpGuard helps
Managing authentication information at scale requires visibility into where credentials are compromised and which workforce behaviors create risk.
- User Risk: Discovers compromised credentials across the workforce by monitoring third-party breach exposure, identifies Shadow AI usage that may expose authentication tokens to unsanctioned services, and delivers real-time coaching that builds measurable, secure credential habits.
For organizations implementing 5.17, that workforce-level visibility closes the gap between policy and practice.
Start a free trial to experience the UpGuard cybersecurity platform.