A.5.17 Authentication information: requirements and evidence

What A.5.17 authentication information requires in ISO 27001

A.5.17 requires that the allocation and management of authentication information, such as passwords, keys and tokens, is controlled through a management process, and that personnel are advised on how to handle that information properly. When the auditor asks how credentials are issued, changed and retired, the answer must be a documented process with records behind it, not a set of habits. A.5.17 merges three ISO/IEC 27001:2013 controls: A.9.2.4 Management of secret authentication information of users, A.9.3.1 Use of secret authentication information and A.9.4.3 Password management system. Your compliance lead should confirm which of the three older controls their previous Statement of Applicability referenced, so the mapping carries over cleanly into the 2022 record.

The control is about governance of secrets, while A.8.5 Secure authentication covers the technical mechanisms that verify identity at login, such as multi-factor checks and session rules. An auditor will test both, but they will test them separately. For A.5.17, expect requests for the issuance procedure, the rules for first-time credentials and resets, evidence that users were told how to protect their credentials, and records showing how a lost or exposed secret was handled. Your self-hosted identity provider, such as authentik, can produce some of this evidence through enrollment and recovery-code records, but the procedure itself must be written and approved by the organization.

Three problems usually make this control hard. Secrets are scattered across ticketing systems, chat threads, CI variables and configuration files, so no one can show a complete picture. Shared accounts used by operations teams have no single owner who can rotate their credentials. Machine credentials such as service account keys and API tokens rarely have an expiry date or a named owner. Start with an inventory of where authentication information lives, then assign an owner to each category. Tools such as OpenBao can hold and issue short-lived credentials, and GitLab pipeline secret detection can flag secrets committed to repositories, but the organization must still decide the rules those tools enforce.

Which systems, secrets and teams fall under A.5.17

A.5.17 applies to every piece of authentication information the organization issues, stores or relies on, not just user passwords. The scope decisions below determine who owns each credential, who issues it and which process must control it. Map each category to an owner before you write the procedure, because an unowned credential is the one an assessor finds.

Human login credentials

Passwords, passphrases and second-factor enrollments for employees, contractors and customers. The question for A.5.17 is who issues the initial secret, how users receive it, and how it is reset when someone forgets it or leaves. Check that the identity team owns issuance and that the process covers enrollment of second factors such as authenticator apps, WebAuthn and passkeys, not only the password itself. Confirm the identity provider's enrollment and reset flows are written down.

Service accounts and machine identities

Accounts that let applications, batch jobs and integrations log in to other systems. These often carry long-lived passwords set by the team that built the system and never rotated. For A.5.17, assign each service account a named owner, record where its secret is stored and define who may change it. Auditors frequently sample these accounts because they sit outside the joiner, mover and leaver process that covers people.

API keys and tokens

Keys and bearer tokens issued to developers, partners and automated clients to call APIs. Scope them to a purpose, record the issuing owner and set an expiry or rotation rule. The control question is whether the organization can list every active key, revoke one quickly and show who approved its creation. Keys pasted into tickets, chat or shared documents are a common finding, so check how issuance is communicated as well as how it is stored.

Certificates and private keys

TLS certificates, code-signing keys and client certificates used to prove identity between systems. A certificate is authentication information when it is used to authenticate, so it needs an inventory with owners, renewal dates and a documented process for issuing and revoking it. Private keys deserve the strictest handling because a copy outside the controlled store can impersonate the owner. Confirm which team holds the certificate authority and which teams request certificates.

CI/CD and pipeline secrets

Credentials that pipelines use to deploy code, pull images or reach production, stored as variables, runner settings or files. These are often created by a developer once and then inherited by every project. Decide which pipelines may receive which secrets, who approves changes to them and how secrets are removed from code and logs. Pipeline secret detection can scan committed files for exposed secrets, but the scan does not replace an issuance process.

Third-party and cloud-managed credentials

Credentials held by suppliers, managed cloud services or SaaS platforms that your staff or systems use, including administrator accounts, SSO connections and vendor-issued API keys. Responsibility is split: the provider may generate and store the secret, while the organization still decides who may hold it and when it is rotated. Record each one in the inventory, confirm what the supplier contract says about credential handling, and check whether the provider offers shared-responsibility documentation you can cite.

How an assessor tests authentication information controls

This table sets out each test step an assessor is likely to take for A.5.17, the evidence requested for it and the findings that most often appear. Read it as a preparation checklist: if you cannot produce the evidence in the right-hand column for a step, expect that step to become a finding.

Test step	What the assessor checks	Evidence requested	Common findings
Review the management process	Whether issuing, changing, resetting and revoking authentication information follows a documented, approved process with named owners	Authentication information procedure, approval records, role assignments for issuance and revocation	No written process, or a procedure that describes the identity tool but not the secrets it issues
Sample issued credentials	Whether each sampled account, service or key traces to an authorized request and is recorded in a register	Credential or secrets register extract, request tickets, issuance logs for a sample of accounts and service identities	Credentials in use that appear in no register, or register entries with no owner or expiry
Check default and initial passwords	Whether vendor defaults and initial passwords are changed before go-live and that the change is enforced	Hardening records, build checklists, configuration exports showing default accounts disabled or renamed	Factory credentials still active on appliances, databases or network devices
Verify staff guidance	Whether personnel receive advice on handling authentication information and have acknowledged it	Guidance document, training materials, signed or electronically recorded acknowledgements with dates	Guidance exists but acknowledgements are missing for leavers, contractors or new starters
Test shared and privileged secrets	Whether shared administrative passwords are avoided, or controlled and attributable when unavoidable	List of shared accounts, check-out logs, rotation records, privileged access approvals	Shared administrator passwords kept in spreadsheets, chat or wiki pages with no rotation
Locate secret stores	Whether the organization knows where authentication information is stored and how it is protected	Inventory of password managers, vaults and key stores, access lists, encryption or access configuration	Undocumented secret stores, secrets in source code or configuration files, unmanaged personal password vaults in use for business systems
Review exception handling	Whether exceptions to password or key rules are approved, time-limited and reviewed	Exception register, risk acceptances, approval records and review dates	Permanent exceptions with no approver or expiry date
Check compromised secret handling	Whether suspected or confirmed compromise triggers revocation, rotation and incident records	Revocation logs, rotation records, incident tickets linked to affected credentials	Compromised keys or tokens left active after an incident, or no record linking the incident to rotation

Steps to implement a controlled authentication information process

This sequence turns A.5.17 from a policy statement into a managed process: every credential has a known owner, a defined issuance and rotation rule, a home in a controlled store, and written guidance for the people who handle it, all reviewed on a fixed cycle that produces records an auditor can sample.

Inventory authentication information by type and owner
Start by listing every kind of authentication information in use: user passwords, service account passwords, API keys, signing keys, tokens, certificates and recovery codes. For each item, record the system it belongs to, the named owner accountable for it, where it is stored today and who can read it. Include information held in configuration files, CI/CD variables and personal password managers used for shared accounts. The output is a secrets register that the security team and system owners sign off. The step is done when a sample of live systems can be traced back to a register entry with an owner.
Define allocation and rotation rules
Write the rules that govern how each type of authentication information is issued, changed, rotated and retired. Cover initial allocation to users and non-human identities, minimum complexity or length where passwords remain, rotation triggers such as suspected exposure or staff change, and how default or temporary credentials are forced to change. Confirm the rules with the relevant standards for your sector and your own risk assessment, since the authentication requirements in A.8.5 and related controls depend on them. The output is a short allocation and rotation standard, approved by the control owner and linked to the register.
Select a central secrets store
Choose one controlled place where machine secrets, keys and dynamic credentials are stored and issued, rather than leaving them spread across scripts and repositories. Open-source options include OpenBao (MPL-2.0), which stores secrets encrypted in one place, can generate short-lived credentials for systems such as databases, attaches leases that revoke secrets on expiry, and can revoke single secrets or whole trees of credentials. Confirm the specific features, deployment model and integrations you need with the vendor before committing. The output is an architecture decision record and a migration list that maps each register entry to its new location.
Enforce issuance through the identity platform
Configure the identity platform so that user authentication information is issued and checked through controlled flows rather than ad hoc resets. For example, authentik's authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, and static recovery codes. FreeIPA supports HOTP and TOTP tokens, including software and hardware tokens, and can proxy OTP checks to an existing RADIUS server during migration. Test each enrollment, reset and recovery path and record the results. The output is a tested configuration baseline and a set of test records showing that enrollment and recovery follow the allocation rules.
Add secret scanning to pipelines
Stop credentials from entering source control by adding automated checks to the development pipeline. GitLab Community Edition (MIT) provides pipeline secret detection that scans files committed and pushed to the repository in a CI/CD job and writes findings to a gl-secret-detection-report.json artifact. Decide whether a finding blocks the merge or raises an alert, define who triages it, and set the response for confirmed exposure, which normally means rotation in the secrets store. Confirm which scanning coverage applies to your repository host. The output is a pipeline configuration, a triage procedure and a log of findings with their resolution.
Write staff handling guidance
Advise personnel on the appropriate handling of authentication information in a short, plain document that people will actually read. Cover choosing and storing passwords, using approved password managers, never sharing personal credentials, reporting suspected exposure, handling recovery codes and keeping keys off personal devices. Tailor separate sections for administrators and developers who handle machine secrets. Require staff to acknowledge the guidance when they join and after material changes. The output is a signed or acknowledged guidance document and a record of acknowledgements linked to the joiner process.
Set a review cycle and keep the records
Set a fixed review cycle for the process and trigger extra reviews after incidents, major system changes or staff departures. At each review, reconcile the secrets register against the live systems, check that rotation rules were followed, review scanning findings and confirm that revoked credentials are gone from the store and pipelines. Record the outcome, the actions raised and their owners. The output is a dated review record and an updated register that an internal or external auditor can sample against the controls. Confirm the review frequency with your own risk assessment and any contractual or regulatory requirements that apply.

Evidence that passes A.5.17 and how to keep it current

An assessor testing A.5.17 looks for a controlled process that you can show operating over time, not a single policy document. The artifacts below form that trail, and each one needs a defined owner and refresh rhythm so the evidence still matches reality when the auditor samples it.

Authentication management procedure

This is the documented process that governs how authentication information is issued, stored, changed, reset and retired for people, service accounts and systems. Assessors check that it names owners, covers each credential type in use, and matches what engineers actually do. Refresh it when a new identity provider, secrets store or credential type is adopted, and at least at your planned review interval, recording the approver and date of each revision.

Secrets register

A register lists every credential in scope, including its type, owning system, owner, storage location and rotation requirement. Auditors compare it against sampled systems to detect secrets that exist outside the register, which is the most common gap they find. Reconcile it against discovery scans and infrastructure inventories each quarter, and record who approved each new entry. Confirm with your team whether your secrets platform can export this inventory directly.

Issuance and revocation logs

These logs show when credentials were created, to whom, and when they were revoked after a departure, role change or suspected exposure. They are the trail that proves the joiner, mover and leaver steps described in your procedure really ran. Keep them in a tamper-resistant store that your access control and audit logging feed, and sample a set of recent leavers each cycle to confirm their credentials were revoked on time.

Rotation and expiry records

Rotation records show that passwords, API keys, certificates and dynamic credentials were changed on the schedule your procedure sets, or that short-lived credentials expired as designed. For dynamic secrets, the lease history itself can serve as the record. Review the schedule against the register at each cycle and document any credential that missed rotation, with the reason and a corrective action.

Secret scan reports

Scanning reports show whether credentials were committed to source code or pipelines, which is a direct failure of the handling expectations in A.5.17. Keep the report from each scheduled run, track findings to closure with an owner and date, and note any false positives you accepted. Pipeline scanning produces a machine-readable artifact per run, so retention of those artifacts becomes part of your evidence set. Confirm the scan covers every repository in scope, not only the main ones.

Staff guidance and acknowledgements

Guidance tells personnel how to create, store, share and report authentication information, such as using a password manager, never pasting tokens into tickets, and reporting suspected exposure. Assessors look for signed or recorded acknowledgements from current staff and evidence that new joiners receive the guidance. Refresh the guidance when the procedure changes and re-collect acknowledgements from a sample of staff and contractors each cycle.

Exception approvals

Exceptions cover cases where a shared account, legacy system or vendor appliance cannot meet the standard rotation or MFA rules. Each one should have a stated business reason, a named risk owner, a compensating control, and an expiry date. Auditors test whether exceptions are rare, approved before use and actually closed or renewed on time. Review the open exception list at every management review and retire any that have lapsed.

How self-hosted tools produce authentication evidence

An auditor testing A.5.17 wants records that show authentication information is issued, used and retired under control, and three self-hosted components can generate much of that trail. The first is the identity platform. authentik's authenticator validation stage checks enrolled second factors during login, including TOTP apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. Its login and enrollment events show which factors a user registered and which ones were used, and the stage configuration itself is evidence of what the organization allows. Confirm in your own environment which events are retained, where they are exported and how long your log store keeps them, because the auditor will ask for samples across a period, not a screenshot of the setting.

FreeIPA covers the directory side. Its OTP support for HOTP (RFC 4226) and TOTP (RFC 6238) tokens, including software tokens enrolled by QR code and hardware tokens such as YubiKeys, creates a per-user token inventory that you can export and reconcile against your joiner, mover and leaver list. If you migrate from an existing RADIUS server, FreeIPA can proxy OTP checks to it during the transition, so the evidence for that period comes from two systems. Document the cut-over date and keep both sets of records. Ask your identity team to confirm how token enrollment and revocation are logged in your version.

OpenBao and GitLab address credentials that never belong to a person. OpenBao stores secrets encrypted in one place, issues dynamic short-lived credentials for systems such as databases, attaches leases that revoke secrets on expiry, and can revoke a single secret or a whole tree of credentials. Lease and revocation records show that machine authentication information has a defined lifetime and a tested removal path. GitLab Community Edition's pipeline secret detection scans committed and pushed files in a CI/CD job and writes findings to a gl-secret-detection-report.json artifact, which gives you a dated record of exposed keys or passwords and of the response taken. Ask your engineers to confirm the scan runs on every branch that can reach production and that findings are triaged in a tracked issue.

What meeting A.5.17 costs in money and effort

This table breaks the cost of meeting A.5.17 into its components, showing who is paid for each, whether it is one-time or recurring, and what pushes it up or down. Use it to scope a quote and to see where self-hosted open-source tools remove license spend. No fixed figures are given because none were supplied for this control.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it up or down
Tooling or licenses	Software vendor or open-source project; the organization pays for hosting and staff time	Recurring for commercial licenses; one-time for setup of self-hosted tools	Number of users and identities; self-hosting removes per-seat license fees but adds infrastructure and upkeep
Engineering time to migrate and configure	Internal platform or security staff, or an implementation partner under a written scope	One-time	Legacy integrations, shared accounts, and how many systems still hold local passwords or static keys
Secrets and machine identity migration	Internal engineers or an implementation partner	One-time, then ongoing as new services appear	Count of service accounts, API keys, certificates and CI/CD credentials that must move into a managed store
Evidence upkeep	Internal control owner, with partner support if retained	Recurring	Frequency of reviews, rotation schedules, and how automatically logs and reports are produced
External testing or review	Independent testers or assessors engaged by the organization	Recurring, usually tied to test cycles	Scope of authentication flows, number of internet-facing login points, and depth of testing agreed in advance
Auditor sampling time	The certification body or independent auditor, whose fees are set in their own agreement	Recurring, in each audit cycle	Number of systems and personnel sampled, and how quickly staff can produce records on request
Training and personnel guidance	Internal HR or security team, or a training provider	Recurring, with onboarding for new staff	Staff turnover and how often guidance on handling credentials is refreshed

Who does what: your team, a partner and the auditor

Your organization owns the control. A.5.17 asks for the allocation and management of authentication information to run through a controlled management process, and that process has to be set and run by people inside the organization. Your security function writes the rules for passwords, keys, tokens and recovery codes, decides who may issue them, and records exceptions with an owner and an expiry date. Someone in the business must also answer for each exception, because an auditor will ask who accepted the risk.

Policy and standards: Approve the rules for password strength, secret rotation, token lifetime and handling, and record who approved them and when they were last reviewed.
Authentication register: Keep a current list of shared accounts, service credentials, API keys and break-glass secrets, with an owner for each.
Exceptions: Approve, time-limit and review any deviation from the rules, and keep the decision record.
Personnel guidance: Tell staff how to handle their own credentials, including never sharing them and reporting suspected exposure.
Operation: Run rotation, revocation and leaver handling as ongoing work, not a one-off project.

Before you engage anyone, confirm that your register and exception process exist in writing, because a partner can configure tools but cannot decide your risk appetite.

Common gaps that fail authentication information audits

Most A.5.17 findings are not about weak algorithms. They come from accounts and secrets that nobody owns, credentials that never rotate, and guidance that staff were given but never confirmed they read. Assessors sample these areas because the gaps are easy to find in a few hours of review.

Shared administrator accounts

Several engineers log in with one administrator account, so the authentication information has no single owner and no individual accountability. Assessors ask who knows the password, when it last changed, and how a departing engineer's access was removed. Check whether each privileged user has a named identity, and whether any shared account still exists in directories, consoles or hypervisors. Where a shared account cannot be removed, record the owner, the custodian and the controls that compensate for it.

Secrets hardcoded in repositories

Passwords, API keys and tokens committed to source code or configuration files are authentication information held outside any controlled process. Once a secret reaches version history it is difficult to prove it was removed everywhere. Run secret detection on repositories and CI/CD pipelines, and treat every hit as a rotation event, not just a deletion. GitLab Community Edition's pipeline secret detection writes its findings to a report artifact, which can serve as recurring evidence.

No rotation record

Organizations often say credentials rotate, but cannot show when a given secret last changed, who approved the change, or what systems depended on it. An assessor will pick a sample of credentials and ask for the rotation history. Confirm that each rotation has a date, an owner and a link to the affected systems. Where dynamic credentials are used, the lease records of a secrets manager can show expiry and revocation directly, reducing the manual record keeping.

Undocumented service credentials

Service accounts, database users and integration tokens often sit outside the identity system and are created by whoever built the integration. They rarely appear in the asset inventory or the access reviews, so nobody knows they exist until an incident. Build a register that lists each service credential, its purpose, its owner and the location where it is stored. Confirm the register matches what is actually configured by sampling the systems themselves.

Staff guidance never acknowledged

A password standard that sits on an intranet does not show that personnel know how to handle authentication information. A.5.17 expects advice to personnel, and assessors usually ask for proof that the guidance reached the people it covers. Check that handling rules, such as not sharing credentials, not writing them down and reporting suspected exposure, are issued to each role and acknowledged. Keep the acknowledgement records with dates and retain them for the period auditors will sample.

Questions buyers ask about A.5.17 cost, effort and audits

How much effort does A.5.17 authentication information take to meet?

A.5.17 takes less effort than most organizational controls if the organization already has an identity provider and a password or secrets tool, but the effort lies in making the process consistent and provable. The work usually splits into writing the authentication information procedure, mapping every account type (human, service, API key, certificate, recovery code), setting rules for allocation, storage, rotation and revocation, and collecting records that show the process ran. Effort rises with the number of systems that issue their own credentials and with the number of shared or non-human accounts. Ask any partner or consultant to break its estimate down by these components so you can see where the time goes.

Can a small team meet A.5.17 without outside help?

Yes, a small team can meet A.5.17 alone if one person owns the process and the team already controls its accounts centrally. The control asks for a managed process and advice to personnel, not for specialist tooling, so a short procedure, a written handling guidance page for staff, and a register of authentication information types can be enough for a small scope. Teams struggle when credentials sit in spreadsheets, chat messages or individual laptops, because the evidence then depends on memory. Before you decide, confirm with your certification body how it expects a small scope to be sampled.

What does an implementation partner add to A.5.17 work?

A partner prepares systems and evidence; it does not own the control or issue the certificate. In practice, a partner can deploy and configure the tools that enforce the process, such as a secrets manager for dynamic credentials, an identity provider with enforced second factors, and pipeline scanning for committed secrets, and can document how each tool produces records. The organization still approves the policy, assigns owners, and accepts the residual risk. An independent auditor or certification body then tests the result. Ask the partner which records it will hand over at the end and who keeps them afterward.

How does A.5.17 differ from A.8.5 secure authentication?

A.5.17 covers the management process for authentication information, while A.8.5 covers the technical mechanisms that verify identity at login. A.5.17 asks who issues passwords, keys and tokens, how they are stored, rotated and revoked, and what staff are told about handling them. A.8.5 asks whether the login itself is secure, for example whether multi-factor checks are enforced and whether sessions are protected. An auditor may test both together, but the evidence differs: A.5.17 relies on procedures, registers and issuance records, and A.8.5 relies on configuration and login tests. Keep them in separate sections of your Statement of Applicability so each has its own owner.

How long does preparing for A.5.17 usually take?

No duration for A.5.17 has been researched for this page, so treat any timeline from a vendor or consultant as an estimate to confirm. Preparation time depends on how many systems issue credentials, whether a central identity or secrets platform already exists, and how much existing practice must be written down and enforced. The work runs in parallel with the wider ISMS, so the control often waits on policy approval and on the asset inventory. Ask for a milestone plan with dated deliverables, and confirm with your certification body when it will sample the records.

What should I ask for in a quote covering A.5.17?

A useful quote states the scope in writing, the systems and account types included, and the deliverables produced. Ask for the list of authentication information types covered, the procedure and staff guidance to be written, the tools to be deployed or configured, and the evidence each one will generate. Confirm what is one-time work, such as design and deployment, and what recurs, such as rotation reviews, tool upgrades and support. Also ask what the quote excludes, who pays for the independent audit, and how changes to scope are priced. DeployOpen works from a written scope, so a quote follows once that scope is agreed.

Which evidence will an auditor sample for A.5.17?

Auditors usually sample the authentication information procedure, the register of credential types and owners, records of issuance and revocation, and evidence that staff received handling guidance. They may also pick a few systems and ask how their credentials are created, stored and rotated. Tools help here: a secrets manager can show leases and revocations, and a pipeline secret detection report can show committed secrets that were found, but the records must still be retained and reviewed. Confirm the exact sampling approach with your certification body before you build the evidence set.

How DeployOpen prepares authentication controls and evidence

DeployOpen's work on A.5.17 starts with a written scope that names the systems, user populations, service accounts and secret stores in play, and which of them the organization wants brought under a controlled process for allocating and managing authentication information. The scope also records who owns each decision: the organization sets the rules for password policy, token lifetime, recovery and secret rotation, while DeployOpen configures the self-hosted tooling to enforce those rules and documents how it behaves. Deliverables, environments and acceptance steps are agreed before any work begins, so the reader can see exactly what the auditor will be shown.

Deployment happens inside the client's own cloud accounts, data centers or air-gapped networks. For user-facing authentication, DeployOpen may deploy authentik and configure its authenticator validation stage so that enrolled second factors such as TOTP apps, WebAuthn passkeys and recovery codes are checked at login, and FreeIPA where OTP tokens must be issued to directory users. For machine and application secrets, OpenBao can hold credentials in one encrypted place, issue short-lived dynamic credentials and revoke them on lease expiry. Pipeline secret detection in GitLab Community Edition can scan committed code for exposed secrets. Before go-live, the reader should confirm which of these components are in their environment, who holds the unseal and root material, and whether recovery code handling meets their own policy.

Evidence is prepared for the independent auditor, who alone decides whether the control is operating effectively. DeployOpen can export configuration baselines, enrollment and revocation records, lease and revocation logs, secret detection job reports and the documented procedures that tell personnel how to handle authentication information. DeployOpen does not issue audit reports, attestations or certifications. Ask any partner to show, in writing, which records will be produced, where they are retained and who in the organization signs off on them, and confirm with your certification body how much sampling they expect for this control.

A.5.17 Authentication information