Control Definition
How authentication secrets — passwords, PINs, cryptographic keys, certificates, and tokens — are allocated, distributed, stored, and changed must be governed by a defined management process, and that process must include telling personnel how to handle their authentication information properly.
Control Objective
To ensure the secrets that prove an identity stay known only to that identity — from first issuance through every reset to final retirement.
What This Really Means
A.5.16 creates the identity; A.5.17 governs the secret that proves it. The premise is unforgiving: a secret known to two parties is no longer authentication, it is shared knowledge. Every rule in this control — out-of-band distribution, forced change on first use, verification before reset, vaulting, rotation — exists to keep one secret bound to one identity, because the entire access chain (A.5.15 rules, A.5.16 identities, A.5.18 rights) collapses if anyone can hold the proof.
For human secrets, the control follows the secret through its life. Issuance: a unique temporary credential, delivered over a channel separate from the username, expiring quickly, with a mandatory change at first logon — never a starter password pasted into email or chat, where it persists, searchable and forwardable, forever. Reset: identity verified before reissuance, because the helpdesk reset path is the classic social-engineering door and deserves the same rigor as first issuance. Quality: length and uniqueness over complexity theater, screening against known-breached password lists, and changes driven by indication of compromise rather than the calendar. And user obligations: never share, never reuse work secrets on personal services, report suspected exposure immediately — duties people acknowledge and a password manager makes livable.
Non-human secrets are the modern half of the control, and usually the weaker one. Service-account passwords, API keys, signing certificates, and tokens accumulate in repositories, CI variables, and config files — and repository history preserves a hardcoded secret long after the line is deleted. The expected posture: a vault or secrets manager as the system of record, short-lived credentials or workload identity where platforms allow, secret scanning in pre-commit and CI, rotation on exposure and on the departure of anyone who knew the secret, and vendor default credentials eliminated before any system touches the network.
Auditors test this control by tracing the journey of a secret. How does a new joiner receive their first password? What exactly does the helpdesk verify before a reset? Where do production database credentials live, and who can read them? Was the default admin password changed on the appliance they just sampled? Strong answers come from process and tooling; weak ones start with "usually."
Why It Matters
Year after year, stolen and weak credentials sit at the top of initial-access patterns in breach investigations — attackers log in far more often than they break in. Each failure mode in this control is a documented entry path: a starter password that never got changed, a reset handed to a smooth-talking caller, an API key committed to a public repository, an appliance still answering to the vendor default. None of these requires sophistication to exploit; all of them defeat every control standing behind the login.
Secrets also fail silently. A misconfigured firewall shows up in a scan; a leaked credential works quietly until someone rotates it, and the exposure persists in repository history, chat archives, and forwarded mail long after everyone has forgotten it. That asymmetry is why the control insists on managed distribution and rotation rather than trusting that exposure will announce itself.
Where authentication information is unmanaged, the entry paths multiply:
- •Credential reuse and stuffing – one breached consumer site yields a working work password, and automation tries it everywhere
- •Secrets in repositories – hardcoded keys and connection strings outlive the commit that deleted them, cloned into every fork and laptop
- •Default credentials – appliances, databases, and IoT devices exposed with vendor logins are found by scanners within hours of deployment
- •The reset path as a back door – helpdesks that reissue credentials without verification hand accounts to social engineers politely and on request
- •Plaintext distribution – passwords sent over email or chat persist indefinitely, searchable by anyone who later compromises the mailbox
Implementation Guidance
Define One Management Process for All Secret Types
Write the authentication information policy to cover the full lifecycle — allocation, distribution, storage, change, revocation — for every secret type: user passwords, PINs, keys, certificates, tokens, and service credentials. Name the owning function (typically IAM or security operations) and make the same process govern human and machine secrets, because attackers do not distinguish between them.
Issue Initial Secrets Out of Band and Force a Change
Generate a unique temporary credential per person, deliver it over a channel separate from the one carrying the username, set a short expiry, and force a change at first logon. Verify the recipient is who onboarding says before anything is issued. Where the platform supports it, skip the temporary password entirely with activation links or passwordless enrollment — the best initial secret is one IT never knows.
Harden the Reset and Recovery Path
Script the helpdesk verification: callback to a number on record, manager confirmation, or identity-provider self-service gated by MFA — chosen by risk, with stronger checks for privileged accounts. Log every reset and alert on bursts or repeated attempts against the same account. Treat each reset as a fresh issuance with identical rigor, because attackers target the recovery flow precisely when the front door is strong.
Eliminate Default Credentials at Provisioning
Build default-credential change into hardening baselines and provisioning checklists (A.8.9): no appliance, database, or network device reaches the production network until vendor logins are changed or disabled, and the step is signed off. Sweep the existing estate quarterly with authenticated scans or default-credential checks, and route findings to asset owners with a remediation SLA.
Adopt Modern Quality Rules and an Enterprise Password Manager
Favor length and per-system uniqueness over forced symbol gymnastics, screen new passwords against known-breached lists at the identity provider, and drop scheduled expiry in favor of change-on-compromise unless a regulator requires otherwise. Then make compliance achievable: deploy an enterprise password manager, require it for any secret that must be shared, and let SSO shrink the password count people must manage.
Vault Non-Human Secrets and Scan for Leaks
Move service credentials, API keys, and certificates into a secrets manager and inject them at runtime instead of storing them in code or config. Prefer short-lived credentials and workload identity where platforms support them. Add secret scanning to pre-commit hooks and CI, and treat anything found in repository history as compromised: rotate first, investigate second.
Obligate Users and Respond to Compromise
Have personnel acknowledge their handling duties: never share authentication information, never reuse work secrets on outside services, report suspected exposure immediately — and make the reporting blame-free so people actually do it. Monitor leaked-credential intelligence feeds for your domains, and force targeted resets the moment exposure is confirmed rather than waiting for the next scheduled change.
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.5.17:
Documentation
- Authentication information policy covering allocation, distribution, quality, storage, and revocation of secrets
- Onboarding records demonstrating out-of-band issuance of temporary credentials with forced first-use change
- Helpdesk reset procedure with identity-verification steps, plus reset logs showing the procedure was followed
- Hardening baseline or build checklist evidencing default-credential elimination, with periodic scan results
- Secrets-management standard and repository secret-scanning configuration with remediation records
Interviews
- Helpdesk staff on exactly what they verify before resetting a password — auditors often probe with realistic pretext scenarios
- A developer on where application and database credentials live, how they are obtained, and what happens when one leaks
- IAM or security owner on password quality settings, breached-password screening, and forced-reset response to confirmed compromise
Observations
- A live password reset observed end to end, including the identity verification step
- Direct inspection of identity provider and directory password policy settings against the documented rules
- A vault or secrets manager reviewed live — coverage, access controls, rotation dates — or a CI secret-scanning run examined
Practitioner Insights
The gap I keep finding is between the password policy and the onboarding reality. The policy is immaculate — twelve characters, breach screening, MFA — and then every new joiner receives the same starter password from IT over plain email, unchanged for weeks because nothing forces rotation. The document is not the control; the journey is. Trace one real new joiner from offer letter to first login and fix what you find on that path before polishing the policy any further.
When I audit this control I spend my time on the reset path, because that is where attackers spend theirs. I ask the helpdesk to walk me through a forgotten-password call and listen for what they actually verify — and organizations with sophisticated MFA programs will still reissue credentials to anyone quoting an employee ID and a date of birth. Verification at reissuance is the control that protects every other authentication investment; if it is weak, the rest is expensive theater.
Common Challenges & Solutions
Challenge
Initial passwords and shared secrets are sent over email or chat because it is the path of least resistance.
Solution
Give IT a sanctioned alternative that is just as fast: one-time secret links that expire after a single view, identity-provider activation emails that never contain a password, or passwordless enrollment where the user sets their own first factor after verification. Then prohibit plaintext secrets in collaboration tools and back the rule with DLP patterns that catch violations.
Challenge
API keys and database passwords are hardcoded across repositories, pipelines, and config files.
Solution
Stop the bleeding with secret scanning in pre-commit hooks and CI, then work the backlog: rotate everything scanning finds, because repository history preserves deleted secrets indefinitely. Migrate services onto a vault or platform secrets manager with runtime injection, prioritizing internet-facing and production scopes, and prefer short-lived credentials so a future leak expires on its own.
Challenge
Users maintain one password across work and personal services, and years of forced complexity rules have made it worse.
Solution
Change the economics instead of lecturing: deploy an enterprise password manager, cut the password count with SSO, screen new passwords against breach lists rather than demanding symbol churn, and drop scheduled expiry in favor of change-on-compromise. Pair this with MFA under A.8.5 so a reused password alone no longer equals account takeover.
Challenge
Network gear, appliances, and databases keep entering service with vendor default credentials.
Solution
Make default-credential change a gated step in provisioning — no production network access until the hardening checklist is signed off by the asset owner. Sweep the estate quarterly with default-credential checks, feed findings into the vulnerability process with an SLA, and include the check in acceptance criteria for anything a vendor installs on your behalf.
Challenge
Service-account passwords have not rotated in years because everyone fears breaking production.
Solution
Stop treating rotation as a manual act of courage: move the accounts into a vault that rotates managed credentials automatically, or replace static secrets with short-lived tokens and workload identity where platforms support them. For the stubborn legacy remainder, schedule rotations with the owning team inside change windows, and rotate immediately whenever someone who knew the credential leaves.
