What is ISO 27001 Annex A 5.17 – Authentication Information?

ISO 27001 Annex A 5.17 focuses on how an organization allocates, manages, protects, and uses authentication information.

Authentication information is anything used to prove that a user, administrator, application, device, or service is who or what it claims to be.

Examples include:

• Passwords
• Passphrases
• PINs
• MFA authentication factors
• One-time passwords (OTP)
• Authentication tokens
• Recovery codes
• API keys
• Service credentials
• Private keys
• Application secrets
• SSH keys
• Temporary credentials

The objective is to prevent authentication information from being:

• Shared unnecessarily
• Disclosed to unauthorized people
• Stored insecurely
• Exposed in source code or logs
• Reused improperly
• Left active after it is no longer required
• Easily compromised

Simple Explanation

Authentication information is the digital equivalent of a key. Protect it like a key to your office, server, or bank account.

---

Why is Annex A 5.17 Important?

A company may have excellent access-control policies, but if passwords, API keys, tokens, or other authentication information are poorly protected, attackers may still gain access.

For example:

A developer accidentally commits an AWS access key to GitHub.

An attacker discovers the exposed key.

The attacker uses it to access the company’s cloud environment.

The problem is not necessarily that the company failed to define access rights. The authentication information itself was compromised.

5.17 helps organizations reduce risks such as:

• Credential theft
• Password disclosure
• Account takeover
• API-key exposure
• Unauthorized administrative access
• Credential sharing
• Secrets stored in source code
• Weak credential recovery processes
• Former employee credentials remaining active
• Compromised service credentials

Simple Principle

Authentication information should be treated as sensitive security information—not ordinary business data.

---

What Does Annex A 5.17 Require?

The organization should establish appropriate controls for the secure management of authentication information throughout its lifecycle.

This includes considering:

1. How authentication information is issued
2. How initial credentials are provided
3. How users are educated about protecting credentials
4. How authentication information is changed or reset
5. How credentials are stored
6. How credentials are transmitted
7. How authentication information is protected from disclosure
8. How compromised credentials are handled
9. How authentication information is revoked or replaced
10. How technical credentials such as API keys and service secrets are managed

The exact implementation should be based on the organization’s:

• Risk profile
• Technology environment
• Access requirements
• Regulatory obligations
• Business processes

ISO 27001 does not mean that every organization must use one identical password policy or authentication technology.

The organization should determine appropriate controls based on its risk assessment and security requirements.

---

What is Authentication Information?

Authentication information is information or an authentication factor used to establish that an identity is legitimate.

Common Examples

Authentication Information	Example
Password	Google Workspace password
Passphrase	Long user-created passphrase
PIN	Device PIN
OTP	Six-digit authentication code
MFA factor	Authenticator application
Recovery code	Emergency MFA recovery code
API key	Application API credential
Access token	OAuth or application token
SSH key	Server authentication key
Private key	Cryptographic authentication key
Service credential	Database service account credential
Client secret	Application authentication secret
Certificate	Client authentication certificate

---

Authentication Information vs Identity vs Access

These three concepts are closely related but different.

Concept	Meaning	Example
Identity	Who or what is requesting access?	John / application XYZ
Authentication	How do we verify it?	Password + MFA
Access	What is it allowed to do?	Read production database

Related ISO Controls

A.5.16 – Identity Management

Answers:

Who is this identity?

A.5.17 – Authentication Information

Answers:

How is the authentication information assigned, protected and managed?

A.5.18 – Access Rights

Answers:

What is this identity allowed to access?

A.8.5 – Secure Authentication

Addresses secure authentication mechanisms and implementation.

---

Types of Authentication Information a Startup Should Consider

1. User Passwords

Examples:

• Google Workspace
• Microsoft 365
• Jira
• Salesforce
• Internal applications

Organizations should define how passwords are created, protected, changed, reset, and recovered.

---

2. MFA Information

Examples:

• Authenticator applications
• Hardware security keys
• OTP
• Recovery codes
• Push authentication

MFA information should also be protected.

For example, recovery codes should not be casually stored in:

• Slack
• Email
• Public documents
• Shared spreadsheets
• Source repositories

---

3. API Keys

API keys are particularly important for startups.

Examples:

• AWS keys
• Stripe API keys
• OpenAI API keys
• GitHub tokens
• Cloud provider credentials
• Third-party integration credentials

They should not be placed directly into source code.

---

4. Service Account Credentials

Applications often authenticate to:

• Databases
• Cloud services
• Internal APIs
• Monitoring platforms
• Backup systems
• CI/CD platforms

These credentials need an identified owner and appropriate protection.

---

5. Cryptographic Keys

Examples include:

• SSH keys
• Private keys
• TLS certificates
• Signing keys
• Encryption keys

These can provide extremely powerful access and therefore require strong protection.

---

Activities Required to Implement A.5.17

Step 1: Identify Authentication Information

Create an inventory of the major types of authentication information used by the organization.

For example:

Type	Example	Owner	System
User password	Google Workspace	IT	Google
API key	AWS	DevOps	AWS
Token	GitHub	Engineering	GitHub
Service credential	PostgreSQL	DevOps	Production
SSH key	Production server	Engineering	Linux

You don’t necessarily need to record actual secrets in the inventory.

Never create a register containing plaintext passwords or secret values.

---

Step 2: Define Secure Handling Requirements

Document rules for:

• Passwords
• MFA
• API keys
• Tokens
• SSH keys
• Service credentials
• Recovery codes
• Certificates
• Private keys

For example:

Authentication information must not be shared through unsecured channels or stored in publicly accessible locations.

---

Step 3: Prohibit Credential Sharing

Users should generally have individual authentication information.

Avoid situations such as:

Bad practice:

admin@company.com

Password:

Company@123

Shared by five employees.

This makes accountability difficult.

Better approach

Each administrator receives:

• Individual identity
• Individual authentication
• Appropriate privileges
• MFA
• Audit logging

Where a shared technical account is genuinely required, it should have an identified owner and compensating controls.

---

Step 4: Use a Password Manager

For organizations with multiple systems, a business password manager can help protect credentials.

Examples of functionality include:

• Encrypted password storage
• Controlled sharing
• Access management
• MFA
• Password generation
• Audit logs
• Employee offboarding

The important point is not the particular product.

The important point is that authentication information should be stored and shared securely.

---

Step 5: Protect Secrets in Applications

Developers should never hard-code sensitive credentials into application source code.

Avoid

AWS_SECRET_KEY = "xxxxxxxxxxxxxxxx"
DATABASE_PASSWORD = "MyPassword123"
API_KEY = "sk-xxxxxxxx"

Instead, use appropriate mechanisms such as:

• Environment variables
• Secrets managers
• CI/CD secret stores
• Cloud secret-management services
• Managed identity mechanisms

---

Step 6: Protect Authentication Information During Transmission

Authentication information should not be transmitted through inappropriate channels.

Avoid sending credentials through:

• Public Slack channels
• Unencrypted email
• WhatsApp groups
• Public tickets
• Shared spreadsheets
• Git repositories

Where credentials must be transferred, use approved secure mechanisms.

---

Step 7: Establish Password Reset Procedures

The organization should define how lost or compromised credentials are reset.

For example:

User reports lost password

↓

Identity verification

↓

Credential reset

↓

MFA verification/re-enrollment if required

↓

Old authentication information invalidated

↓

Event logged

---

Step 8: Manage Compromised Credentials

If an API key, password, token, or private key is suspected to be compromised, the organization should have a defined response.

Example:

Credential exposure detected

→ Disable/revoke credential

→ Generate replacement

→ Investigate potential use

→ Review logs

→ Assess impact

→ Document incident

→ Implement preventive action

---

Step 9: Manage Service Credentials

Every important service credential should have:

• Owner
• Purpose
• System
• Creation date
• Review date
• Expiration/rotation requirements where applicable
• Appropriate privileges
• Status

Again, record the metadata, not the actual secret.

---

Step 10: Educate Users

Employees should understand basic authentication security.

Training should cover:

• Don’t share passwords
• Don’t reuse business passwords
• Don’t disclose MFA codes
• Don’t approve unexpected MFA requests
• Don’t store credentials in unsecured documents
• Don’t put secrets into source code
• Report suspected credential compromise
• Use approved password managers
• Protect recovery codes

---

Startup Example

Imagine a 50-person SaaS company using:

• Google Workspace
• GitHub
• AWS
• Jira
• Slack
• Salesforce
• PostgreSQL

The company identifies:

User authentication

Google Workspace → Password + MFA

Developer authentication

GitHub → SSO + MFA

Cloud authentication

AWS → SSO/IAM + MFA

Application authentication

AWS Secrets Manager → Application secrets

Server authentication

SSH keys → Managed through approved process

Third-party integrations

API keys → Stored in approved secrets management system

The company documents who owns these authentication mechanisms and establishes procedures for creating, protecting, rotating, revoking, and recovering them.

---

Startup-Focused Quick Summary

A startup doesn’t need an enormous authentication-management bureaucracy.

A practical approach is:

Identify → Protect → Restrict → Monitor → Rotate/Reset → Revoke

Minimum practical controls

Area	Startup Practice
Passwords	Individual accounts
MFA	Enabled for important systems
Password storage	Approved password manager
API keys	Secrets manager
Source code	No hard-coded credentials
Admin accounts	Individual identities
Recovery codes	Secure storage
Service accounts	Named owner
Compromised credentials	Immediate revocation/replacement
Offboarding	Credentials disabled/revoked
Training	Basic credential-security awareness

---

Example Authentication Information Register

The organization can maintain a register such as:

Credential/Secret Type	System	Owner	Purpose	Storage	Rotation/Review	Status
API Key	AWS	DevOps	Application	Secrets Manager	Defined process	Active
Service Credential	PostgreSQL	Engineering	Application DB	Secrets Manager	Defined process	Active
SSH Key	Production Server	DevOps	Administration	Approved key management	Periodic review	Active
OAuth Token	CRM	IT	Integration	Approved vault	As required	Active
Admin Authentication	Google Workspace	IT	Administration	SSO/MFA	Periodic review	Active

Do not put actual passwords, API keys, tokens, private keys, or other secrets in this register.

---

What Evidence Can an Auditor Ask For?

An auditor may want to see evidence that authentication information is appropriately managed.

Policy Evidence

• Information Security Policy
• Access Control Policy
• Authentication Policy
• Password/Authentication Standard
• Secrets Management Policy
• Acceptable Use Policy

Process Evidence

• User onboarding procedure
• Password reset procedure
• Credential compromise procedure
• API key management process
• Service-account management process
• Offboarding procedure
• MFA enrollment process

Technical Evidence

Depending on the environment:

• MFA configuration
• SSO configuration
• Password manager configuration
• Secrets manager configuration
• GitHub secret scanning
• Cloud IAM configuration
• API key management
• Authentication logs
• Credential rotation records
• Access logs

Operational Evidence

• Credential reset records
• API key rotation records
• Service account reviews
• Offboarding records
• Security awareness training
• Incident records involving compromised credentials

---

ISO 27001 A.5.17 Audit Checklist

An auditor may ask:

Authentication Information

• Are authentication mechanisms defined?
• Are authentication credentials securely allocated?
• Are initial credentials securely provided?
• Are users instructed not to disclose authentication information?
• Are passwords protected from unauthorized disclosure?
• Are MFA factors appropriately protected?
• Are recovery codes protected?

User Credentials

• Does each user have individual authentication?
• Are shared credentials prohibited or controlled?
• Are administrator credentials individually attributable?
• Is there a process for resetting forgotten credentials?
• Is there a process for compromised credentials?

Technical Credentials

• Are API keys managed securely?
• Are secrets prevented from being stored in source code?
• Are service credentials assigned an owner?
• Are SSH keys appropriately managed?
• Are inactive credentials revoked?
• Are credentials replaced when compromise is suspected?

Lifecycle

• Are authentication credentials created through an approved process?
• Are they changed or rotated when required?
• Are compromised credentials immediately addressed?
• Are credentials revoked when no longer required?

---

Common Mistakes

1. Treating passwords as the only authentication information

Authentication information also includes:

• API keys
• Tokens
• SSH keys
• Private keys
• Service credentials
• Recovery codes

---

2. Storing passwords in Excel

A spreadsheet containing production passwords is a significant security concern.

Use an approved credential-management mechanism instead.

---

3. Putting API keys in GitHub

Example:

API_KEY = "production-secret"

Even if the developer later deletes the line, the credential may already exist in repository history.

The credential should be treated as potentially exposed and appropriately revoked/replaced.

---

4. Sharing admin passwords

A shared administrator password makes accountability difficult.

Use individual privileged identities wherever practical.

---

5. Ignoring recovery codes

Organizations sometimes protect passwords and MFA but leave recovery codes in unsecured documents.

Recovery information should receive appropriate protection.

---

6. No process for compromised credentials

A company may have a password policy but no documented process for:

“What do we do when an API key is accidentally exposed?”

This should be addressed.

---

7. No owner for service credentials

A service account called:

production-api

should have an accountable owner.

Otherwise, nobody may know whether the credential is still required.

---

Practical Startup Implementation Model

A startup can implement A.5.17 using this simple model:

1. Identify

What authentication information do we use?

↓

2. Classify

How sensitive is it?

↓

3. Protect

Where should it be stored?

↓

4. Control

Who can access it?

↓

5. Monitor

Can we detect suspicious use or exposure?

↓

6. Rotate / Reset

When should authentication information be changed?

↓

7. Revoke

What happens when it is compromised or no longer required?

---

Policy vs Process vs Evidence

Component	Example
Policy	Authentication information must be securely managed
Standard	Credentials must not be shared or stored in unauthorized locations
Procedure	How users reset passwords
Procedure	How API keys are created and revoked
Technical Control	MFA
Technical Control	Secrets Manager
Evidence	MFA configuration
Evidence	Credential rotation record
Evidence	Offboarding record
Evidence	Security training

An auditor should ideally be able to see the connection:

Requirement → Process → Control → Evidence

---

Relationship With Other ISO 27001 Controls

Control	Relationship
A.5.15 Access Control	Defines principles for controlling access
A.5.16 Identity Management	Manages identities throughout their lifecycle
A.5.17 Authentication Information	Protects and manages authentication information
A.5.18 Access Rights	Manages rights assigned to identities
A.6.3 Information Security Awareness	Helps users understand credential-security responsibilities
A.6.5 Responsibilities After Termination or Change of Employment	Supports removal of authentication/access after employment changes
A.8.2 Privileged Access Rights	Controls highly privileged accounts
A.8.5 Secure Authentication	Addresses secure implementation of authentication mechanisms
A.8.15 Logging	Supports monitoring of authentication activity

---

Useful Documents for A.5.17

A startup implementing this control may maintain:

1. Authentication & Password Policy
   [Insert Draft Document Link]
2. Secrets Management Procedure
   [Insert Draft Document Link]
3. API Key Management Procedure
   [Insert Draft Document Link]
4. User Onboarding & Authentication Procedure
   [Insert Draft Document Link]
5. Credential Reset Procedure
   [Insert Draft Document Link]
6. Credential Compromise Response Procedure
   [Insert Draft Document Link]
7. Service Account Register
   [Insert Draft Document Link]
8. Authentication Information Register
   [Insert Draft Document Link]
9. Employee Security Awareness Training
   [Insert Draft Document Link]

---

Final Takeaway

ISO 27001 Annex A 5.17 is fundamentally about protecting the information used to authenticate people, applications, devices, and services.

For a startup, the objective is not to create unnecessary bureaucracy.

It is to make sure that:

The right people and systems receive the right authentication information, it is securely protected, it is not unnecessarily shared, and compromised or unnecessary credentials are promptly reset or revoked.

A practical implementation can be summarized as:

Identify → Protect → Restrict → Monitor → Reset/Rotate → Revoke

Key Auditor Questions

Before considering A.5.17 implemented, ask:

• Do we know what types of authentication information we use?
• Are credentials stored securely?
• Are passwords and secrets protected from unauthorized disclosure?
• Is MFA appropriately implemented?
• Are API keys and application secrets protected?
• Can developers accidentally commit secrets to source code?
• Are service credentials owned and managed?
• Is there a process for compromised credentials?
• Are authentication mechanisms removed when no longer required?
• Can we provide evidence that these controls actually operate?

If the answer is yes and supported by evidence, the organization has a much stronger foundation for demonstrating effective implementation of A.5.17.