1. Purpose
The Authentication Information Register is a controlled register used to identify and manage authentication information and authentication mechanisms used by users, administrators, applications, services, and other identities.
The register provides visibility into:
- What authentication mechanisms exist
- Which identity uses them
- Which system they protect
- Who owns them
- What authentication method is used
- Whether MFA is enabled
- Whether the authentication mechanism is privileged
- When it was created, reviewed, rotated, or revoked
- Whether it is active, expired, compromised, or retired
Core Principle
Identify → Assign Owner → Protect → Review → Rotate → Revoke → Record
2. Important Security Rule
The Authentication Information Register must contain metadata only.
Never record:
- Passwords
- API keys
- Access tokens
- Refresh tokens
- MFA secrets
- TOTP seeds
- Recovery codes
- Private keys
- SSH private keys
- Encryption keys
- Cloud secret values
- Database passwords
The register should identify where and how authentication information is managed, not contain the actual secret.
For example:
Correct:Storage: AWS Secrets Manager
Incorrect:Database Password: MySecret123
3. Scope
The register may cover authentication information associated with:
- Employees
- Contractors
- Consultants
- Interns
- Temporary users
- Third-party users
- Privileged users
- Service accounts
- Application identities
- Cloud identities
- Emergency accounts
It may include:
- Password authentication
- SSO
- MFA
- Passkeys
- Security keys
- Certificates
- SSH keys
- API keys
- Access tokens
- Refresh tokens
- OAuth credentials
- Cloud roles
- Service credentials
- Workload identities
- Database credentials
- VPN authentication
4. Master Authentication Information Register
| Field | Description |
|---|---|
| Authentication ID | Unique identifier |
| Authentication Name | Name/description |
| Identity ID | Related identity |
| Identity Name | User/service/application |
| Identity Type | Employee/Contractor/Service/etc. |
| System/Application | Protected system |
| Environment | Production/Development/Test |
| Authentication Provider | IdP/SSO/Cloud/Application |
| Authentication Type | Password/MFA/Key/Token/etc. |
| MFA Enabled | Yes/No/N/A |
| MFA Method | Authenticator/Security Key/Passkey/etc. |
| Business Purpose | Reason authentication is required |
| Privilege Level | Standard/Privileged |
| Information Accessed | Information/data type |
| Classification | Public/Internal/Confidential/Restricted |
| Authentication Owner | Accountable owner |
| System Owner | System owner |
| Secure Storage | Approved storage mechanism |
| Start Date | Activation date |
| Expiry Date | Where applicable |
| Last Rotation | Last credential rotation |
| Next Rotation | Where applicable |
| Last Review | Last review date |
| Next Review | Next review date |
| Status | Active/Revoked/etc. |
| Related Risk ID | Risk reference |
| Related Access Request | Approval reference |
| Related Incident ID | Incident reference |
| Evidence Reference | Supporting evidence |
| Remarks | Additional information |
5. Authentication ID
Each authentication mechanism should have a unique identifier.
Example:
- AUTH-001
- AUTH-002
- AUTH-003
- AUTH-004
The ID should remain stable throughout the lifecycle where practical.
6. Identity Information
The register should identify the identity associated with the authentication mechanism.
Examples:
- Employee
- Contractor
- Administrator
- Service account
- Application
- CI/CD identity
- Cloud workload
- Emergency account
Link the record to the organization’s Identity Register where possible.
7. System/Application
Identify the system protected by the authentication mechanism.
Examples:
- Microsoft 365
- GitHub
- Jira
- AWS
- Azure
- Database
- VPN
- CRM
- Customer portal
- CI/CD platform
- Security platform
8. Environment
Record the relevant environment:
- Production
- Development
- Test
- Staging
- Disaster Recovery
Production authentication should receive appropriate additional protection based on risk.
9. Authentication Type
Use standardized values where practical.
| Type | Example |
|---|---|
| Password | Corporate password |
| SSO | Identity-provider authentication |
| MFA | Authenticator-based MFA |
| Passkey | FIDO/WebAuthn passkey |
| Security Key | Hardware security key |
| Certificate | Client certificate |
| SSH Key | SSH authentication |
| API Key | Application API credential |
| Access Token | OAuth/access token |
| Refresh Token | Token used to obtain access |
| IAM Role | AWS/Azure/GCP role |
| Workload Identity | Application authentication |
| Service Credential | Service/application credential |
10. MFA Information
Where MFA is required, record:
- MFA enabled
- MFA type
- MFA provider
- Enrollment status
- Enrollment date
- Last verification
- Security-key identifier where appropriate
Do not record the actual MFA secret.
11. Privilege Level
Record whether the authentication mechanism supports:
- Standard access
- Elevated access
- Privileged access
- Administrative access
- Emergency access
Example:
| Identity | System | Privilege |
|---|---|---|
| Developer | AWS Development | Standard |
| DevOps | AWS Production | Privileged |
| Security Admin | SIEM | Administrative |
| Application | AWS Production | Application-specific |
12. Business Purpose
Every important authentication mechanism should have a defined business purpose.
Examples:
- Employee access to corporate email
- Developer access to source code
- Application access to production database
- CI/CD deployment
- Security monitoring
- Customer support
- Cloud administration
Avoid unidentified or unexplained authentication mechanisms.
13. Authentication Owner
Each authentication mechanism should have an accountable owner.
The owner is responsible for:
- Business justification
- Appropriate authentication method
- Security requirements
- Periodic review
- Rotation where applicable
- Revocation
- Exception management
The owner does not necessarily need to manage the credential technically.
14. Secure Storage
Record where authentication information is securely managed.
Examples:
- Identity Provider
- Enterprise Password Manager
- AWS Secrets Manager
- Azure Key Vault
- Google Secret Manager
- Certificate Management System
- Hardware Security Module
- Approved Key Management System
Example
| Authentication | Storage |
|---|---|
| Application database credential | AWS Secrets Manager |
| Employee password | Identity Provider |
| API credential | Approved Secrets Manager |
| TLS private key | Approved certificate/key-management system |
| AWS human authentication | SSO/Identity Provider |
15. Password Authentication
For password-based authentication, record:
- Identity
- System
- Authentication provider
- MFA status
- Last password reset
- Last review
- Status
- Applicable password policy
Do not record the actual password.
16. API Key Authentication
For API keys, record metadata such as:
- API ID
- Application
- Environment
- Owner
- Purpose
- Privilege
- Creation date
- Expiry date
- Last rotation
- Next review
- Storage mechanism
- Status
Example
| ID | Application | Environment | Owner | Status |
|---|---|---|---|---|
| AUTH-021 | Payment API | Production | Engineering | Active |
| AUTH-022 | Monitoring API | Production | Security | Active |
The actual API key must remain in an approved secrets-management system.
17. Access Token Authentication
Record:
- Token identifier
- Application
- Identity
- Token type
- Purpose
- Scope
- Issuer
- Expiry
- Owner
- Status
Do not store the actual token.
Short-lived tokens should be preferred where technically practical.
18. SSH Key Authentication
Record:
- SSH Key ID
- User/service
- System
- Environment
- Purpose
- Public-key fingerprint
- Owner
- Creation date
- Review/expiry date
- Status
The private key must never be recorded.
19. Certificate Authentication
For authentication certificates, record:
- Certificate ID
- Subject
- Application/system
- Environment
- Certificate Authority
- Purpose
- Issue date
- Expiry date
- Owner
- Renewal status
- Revocation status
Private-key material must not be recorded.
20. Service Account Authentication
Every important service account should have:
- Owner
- Business purpose
- System/application
- Authentication mechanism
- Privilege level
- Creation date
- Review date
- Expiry date where applicable
- Secure storage mechanism
- Rotation process
- Status
Where supported, use workload identities, managed identities, or temporary credentials instead of long-lived static credentials.
21. Cloud Authentication
For AWS, Azure, or GCP, record:
- Cloud provider
- Account/subscription/project
- Identity
- Authentication method
- Role
- Environment
- Privilege
- MFA requirement
- Owner
- Review status
Example
| Identity | Authentication | Environment | Privilege |
|---|---|---|---|
| Developer | SSO + MFA | AWS Dev | Standard |
| DevOps | SSO + MFA | AWS Production | Privileged |
| Application | IAM Role | AWS Production | Application |
| CI/CD | Workload Identity | AWS Production | Deployment |
22. AWS Authentication Example
A startup may implement:
Employee
→ Corporate Identity Provider
→ MFA
→ AWS IAM Identity Center
→ AWS Role
→ Approved AWS Account
The register records the authentication relationship.
It does not contain:
- AWS passwords
- Access keys
- Secret keys
- MFA secrets
- Recovery codes
23. Privileged Authentication
Privileged authentication should be separately identified.
Examples:
- AWS Administrator
- Database Administrator
- Identity Administrator
- Security Administrator
- Network Administrator
- CI/CD Administrator
Record:
- Identity
- System
- Privilege
- Authentication method
- MFA
- Owner
- Approval
- Last review
- Next review
- Status
Privileged authentication should receive stronger controls appropriate to risk.
24. Emergency Authentication
Break-glass accounts should be recorded.
Record:
- Account
- Purpose
- Owner
- Authentication method
- Protection mechanism
- Approval requirements
- Monitoring
- Last review
- Last test
- Status
Do not record the emergency password or recovery code.
25. Authentication Lifecycle
Authentication information should be managed throughout its lifecycle:
Requirement
→ Create
→ Assign
→ Protect
→ Use
→ Monitor
→ Review
→ Rotate
→ Revoke
→ Retire
→ Record
26. Authentication Creation
Before creating an authentication mechanism:
- Confirm identity.
- Confirm business purpose.
- Identify system.
- Determine required privilege.
- Select appropriate authentication method.
- Obtain approval where required.
- Configure appropriate security controls.
- Record metadata.
27. Authentication Review
Periodic review should determine:
- Is the identity still active?
- Is the authentication mechanism still required?
- Is the owner correct?
- Is the authentication method appropriate?
- Is MFA enabled where required?
- Is the privilege appropriate?
- Has the credential expired?
- Does it require rotation?
- Is it securely stored?
- Should it be revoked?
28. Authentication Reconciliation
The register should be reconciled with relevant systems.
Sources
- HR system
- Identity Provider
- SSO
- AWS IAM/Identity Center
- Azure
- Google Cloud
- SaaS applications
- VPN
- GitHub
- Databases
- API platforms
- Secrets-management systems
- Certificate-management systems
Process
Collect → Compare → Identify Differences → Investigate → Correct → Verify → Update
29. Unknown Authentication Mechanisms
If an unknown authentication mechanism is discovered:
- Identify the associated identity.
- Identify the system.
- Determine its purpose.
- Identify the owner.
- Assess privilege.
- Determine whether it is authorized.
- Revoke if unnecessary or unauthorized.
- Update the register.
- Record the action.
Unknown credentials should not remain active simply because their purpose cannot be determined.
30. Authentication Rotation
Rotation requirements should be based on:
- Credential type
- Risk
- Technology
- Organizational policy
- Supplier requirements
- Exposure
- Security incidents
Do not apply one universal rotation interval to every credential.
Credentials should be rotated or replaced immediately when compromise or exposure requires it.
31. Authentication Revocation
Authentication mechanisms should be revoked when:
- User leaves
- Contractor engagement ends
- Access is no longer required
- Credential is compromised
- MFA device is lost
- System is retired
- Application is decommissioned
- Credential expires
Revocation should be verified where technically possible.
32. Credential Compromise
When authentication information is suspected of compromise:
Detect → Contain → Revoke → Replace → Investigate → Verify → Record
Examples:
- Password exposed → Reset
- API key exposed → Revoke/rotate
- AWS access key exposed → Disable/replace
- SSH key exposed → Revoke/replace
- MFA factor compromised → Revoke/re-enroll
- Token exposed → Revoke
Follow the Credential Compromise Response Procedure.
33. Authentication Change Log
Where appropriate, maintain a separate change log.
| Change ID | Authentication ID | Change | Reason | Owner | Date | Status |
|---|---|---|---|---|---|---|
| CH-001 | AUTH-001 | MFA changed | New device | IT | Date | Closed |
| CH-002 | AUTH-014 | API key rotated | Security action | Engineering | Date | Closed |
| CH-003 | AUTH-025 | Credential revoked | Compromise | Security | Date | Closed |
34. Authentication Information Register — Sample
| ID | Identity | System | Authentication | MFA | Privilege | Owner | Status |
|---|---|---|---|---|---|---|---|
| AUTH-001 | Employee-001 | Microsoft 365 | SSO + Password | Yes | Standard | IT | Active |
| AUTH-002 | Employee-002 | AWS Production | SSO + MFA | Yes | Privileged | CTO | Active |
| AUTH-003 | App-001 | AWS Production | IAM Role | N/A | Application | Engineering | Active |
| AUTH-004 | CI-CD-001 | AWS Production | Workload Identity | N/A | Deployment | DevOps | Active |
| AUTH-005 | Vendor-001 | Audit Repository | SSO + MFA | Yes | Temporary | Security | Active |
| AUTH-006 | Payment-App | Payment API | API Credential | N/A | Application | Engineering | Active |
Examples are illustrative and should be adapted to the organization’s environment.
35. Relationship with Identity Register
The two registers should work together.
Identity Register
Who/what is the identity?
Authentication Information Register
How is that identity authenticated?
Access Control Matrix
What can that identity access?
Secrets Management System
Where is the actual secret securely stored?
This creates the control chain:
Identity → Authentication → Access → Protection → Review
36. Relationship with Secrets Management
The Authentication Information Register should not replace a secrets-management system.
Authentication Information Register
Records:
- Credential type
- Owner
- Purpose
- System
- Storage location
- Rotation status
- Review status
Secrets Management System
Stores:
- Actual password
- API key
- Token
- Private key
- Database credential
- Other secret value
The register describes the authentication information; the secrets-management system protects the authentication information.
37. Relationship with Joiner-Mover-Leaver
Joiner
Create approved authentication mechanisms.
Mover
Review and modify authentication requirements.
Leaver
Revoke authentication mechanisms and access.
Contractor
Apply appropriate expiry and review.
Third Party
Control authentication throughout the engagement.
38. Relationship with Credential Compromise Response
When a credential is compromised:
Authentication Register
→ Identify affected Authentication ID
→ Credential Compromise Response
→ Revoke/rotate
→ Investigate
→ Update status
→ Link Incident ID
→ Review risk
This provides traceability from the authentication mechanism to the security incident.
39. Evidence
Potential audit evidence includes:
- Authentication Information Register
- Identity Register
- Access Review Reports
- MFA configuration
- SSO configuration
- IAM records
- Credential rotation records
- Secrets-management records
- Certificate records
- SSH key records
- Authentication logs
- Revocation records
- JML records
- Incident records
- Exception records
- Review records
Actual passwords, API keys, tokens, MFA secrets, private keys, and recovery codes must never be retained as audit evidence.
40. Review Frequency
Review frequency should be risk-based.
Examples:
| Authentication | Example Review |
|---|---|
| Privileged authentication | More frequent |
| Production credentials | More frequent |
| Service credentials | Periodic |
| Third-party authentication | Aligned with access review |
| Standard user authentication | Aligned with identity/access review |
| Certificates | Before expiry and during renewal |
| Emergency accounts | Periodic and after each use |
These are examples; the organization should define appropriate frequencies based on risk.
41. Metrics
Useful metrics include:
- Total authentication mechanisms
- MFA coverage
- Privileged authentication mechanisms
- Expired credentials
- Credentials requiring rotation
- Orphaned authentication mechanisms
- Unknown authentication mechanisms
- Compromised credentials
- Average credential-revocation time
- Authentication exceptions
- Review completion rate
42. Startup-Friendly Implementation
For a startup, the register can initially be maintained in a controlled spreadsheet or GRC platform.
At minimum, track:
| Authentication ID | Identity | System | Method | MFA | Privilege | Owner | Storage | Last Review | Status |
|---|---|---|---|---|---|---|---|---|---|
| AUTH-001 | Developer-01 | Microsoft 365 | SSO | Yes | Standard | IT | IdP | Date | Active |
| AUTH-002 | DevOps-01 | AWS | SSO + MFA | Yes | Privileged | CTO | IdP | Date | Active |
| AUTH-003 | App-01 | AWS | IAM Role | N/A | Application | Engineering | IAM | Date | Active |
As the organization grows, this can be integrated with IAM, GRC, secrets-management, and cloud-management platforms.
43. Quick Audit Checklist
Identification
- Authentication mechanisms identified
- Related identity identified
- System identified
- Business purpose documented
- Owner assigned
Authentication
- Authentication method documented
- MFA status documented
- Privileged authentication identified
- Authentication provider identified
- Status current
Protection
- Actual secrets are not stored in the register
- Secure storage mechanism identified
- Credential protection requirements defined
- Rotation/revocation process defined
Lifecycle
- Creation recorded
- Expiry recorded where applicable
- Review date recorded
- Rotation tracked where applicable
- Revocation tracked
- Compromised credentials linked to incidents
Review
- Register reconciled with authentication systems
- Unknown mechanisms investigated
- Orphaned mechanisms removed
- Privileged authentication reviewed
- Exceptions reviewed
44. ISO 27001 Connection
The Authentication Information Register supports applicable ISO/IEC 27001 requirements and controls relating to:
- Identity management
- Authentication information
- Access rights
- Secure authentication
- Privileged access
- Access control
- Cryptographic/key management
- Logging and monitoring
- Incident management
The exact applicable controls should be determined through the organization’s risk assessment and Statement of Applicability (SoA).
45. Final Audit Trail
For any important authentication mechanism, the organization should be able to demonstrate:
What authentication mechanism exists?
→ Which identity uses it?
→ What system does it protect?
→ Why is it required?
→ Who owns it?
→ What authentication method is used?
→ Is MFA enabled where required?
→ What privilege does it support?
→ Where is the actual authentication secret securely managed?
→ When was it last reviewed or rotated?
→ Is it still required?
→ Has it been compromised or exposed?
→ When should it be revoked or retired?
→ Can the organization demonstrate appropriate lifecycle management?
Final Principle
Know what authentication mechanisms exist, know which identities use them, know why they are required, protect the actual secrets separately, review them periodically, and revoke them when the business need ends.