What is ISO 27001 Annex A 8.5 – Secure Authentication?
ISO 27001 Annex A 8.5 focuses on implementing secure authentication mechanisms that appropriately protect access to systems, applications, services, devices, and information.
Authentication is the process of verifying that a person, device, or system is actually who or what it claims to be.
Common authentication mechanisms include:
- Passwords
- Multi-factor authentication (MFA)
- Single Sign-On (SSO)
- Security keys
- Authenticator applications
- Biometrics
- Certificates
- Device-based authentication
- Service-to-service authentication
- API authentication
- Hardware tokens
Simple Explanation
Do not assume that someone is who they claim to be just because they know a username or password. Use appropriate authentication controls to verify identity before granting access.
For a startup, secure authentication is one of the most important foundational security controls because a compromised account can provide access to multiple systems.
Why is Secure Authentication Important?
Modern organizations depend heavily on cloud applications and SaaS platforms.
A single employee may have access to:
- Source-code repositories
- Cloud infrastructure
- CRM
- HR systems
- Financial systems
- Collaboration tools
- Security tools
- Customer-support platforms
- VPN
- Production applications
If an attacker compromises that employee’s credentials, the attacker may gain access to several business systems.
Common Authentication Risks
- Weak passwords
- Reused passwords
- Credential theft
- Phishing
- Password spraying
- Brute-force attacks
- Stolen sessions
- Shared accounts
- Lack of MFA
- Poor password-reset processes
- Uncontrolled service accounts
- Weak API authentication
- Insecure recovery mechanisms
- Excessive authentication privileges
Simple Principle
The more sensitive the system or information, the stronger and more carefully controlled the authentication should be.
What Does Annex A 8.5 Require?
The organization should establish and implement appropriate authentication technologies and procedures based on:
- Business requirements
- Information sensitivity
- Risk
- User roles
- Privilege level
- Threat environment
- System criticality
- Regulatory requirements
- Customer requirements
- Remote access requirements
The control does not mean that every system must use the exact same authentication method.
Instead, the organization should determine what level of authentication protection is appropriate for different situations.
Authentication vs Authorization
These terms are often confused.
| Concept | Question |
|---|---|
| Authentication | Who are you? |
| Authorization | What are you allowed to access? |
Example
An employee logs into the company’s GitHub account using MFA.
Authentication:
The organization verifies the user’s identity.
Authorization:
The organization determines which repositories that user can access.
Therefore:
- A.8.5 primarily addresses secure authentication.
- A.8.3 addresses information access restriction.
- A.5.18 addresses access rights.
- A.8.2 addresses privileged access rights.
What is Multi-Factor Authentication?
Multi-factor authentication requires two or more different authentication factors.
The main categories are:
Something You Know
Examples:
- Password
- PIN
Something You Have
Examples:
- Security key
- Authenticator application
- Hardware token
- Registered device
Something You Are
Examples:
- Fingerprint
- Facial recognition
- Other biometric characteristics
A typical MFA login could be:
Username + Password + Authenticator Approval
or:
Password + Security Key
Why MFA Matters
Passwords can be:
- Stolen through phishing
- Reused across services
- Obtained through credential leaks
- Guessed
- Captured by malware
MFA provides an additional authentication factor.
For example:
Attacker obtains password
↓
Attempts login
↓
MFA required
↓
Attacker cannot provide second factor
↓
Access is prevented
MFA is not a complete security solution, but it significantly strengthens authentication when appropriately implemented.
Activities Required to Implement Annex A 8.5
1. Identify Systems Requiring Authentication
Create an inventory of important systems.
For example:
| System | Purpose | Criticality | Authentication |
|---|---|---|---|
| Google Workspace | Email & collaboration | High | SSO + MFA |
| GitHub | Source code | Critical | MFA |
| AWS | Cloud infrastructure | Critical | MFA/strong authentication |
| CRM | Customer information | High | SSO + MFA |
| HR Platform | Employee information | High | SSO + MFA |
| Accounting | Financial information | High | MFA |
| Internal Portal | Business operations | Medium | Password + MFA |
The exact authentication requirements should be based on risk.
2. Identify User Types
Authentication requirements may differ depending on the user.
Consider:
- Employees
- Administrators
- Developers
- Contractors
- Vendors
- Customers
- Temporary users
- External partners
- Service accounts
- System accounts
A cloud administrator should generally receive stronger authentication protection than a low-risk internal application user.
3. Define Authentication Requirements
Create authentication requirements based on risk.
Example:
| System Type | Authentication Requirement |
|---|---|
| Public website | Appropriate application authentication where required |
| Internal application | Strong authentication |
| Business SaaS | MFA/SSO where appropriate |
| Source-code repository | MFA |
| Cloud administration | Strong authentication + MFA |
| Production systems | Strong authentication + controlled privileged access |
| Customer portal | Secure application authentication |
| Security systems | Strong authentication + restricted access |
4. Establish Password Requirements
Where passwords are used, define appropriate requirements.
Consider:
- Minimum password length
- Password quality
- Password reuse
- Password storage
- Failed login handling
- Account lockout or throttling
- Password reset
- Temporary passwords
- Credential recovery
- Compromised-password handling
Passwords should not be stored in plaintext.
Applications should use appropriate secure password hashing mechanisms.
5. Implement MFA for Higher-Risk Access
MFA should be strongly considered for systems such as:
- Cloud administration
- Source-code repositories
- VPN
- Security tools
- Financial systems
- Production environments
- Administrative consoles
- Identity-management platforms
The organization’s risk assessment should determine where MFA is required.
6. Protect Privileged Accounts
Privileged accounts require additional attention.
Examples:
- Cloud administrator
- Domain administrator
- Database administrator
- Security administrator
- Repository administrator
- Network administrator
Consider:
- MFA
- Separate administrator accounts
- Strong authentication
- Limited privileged access
- Monitoring
- Access reviews
- Temporary elevation where practical
- Emergency-access controls
This connects directly with A.8.2 – Privileged Access Rights.
7. Avoid Shared Accounts
Shared accounts reduce accountability.
For example:
admin@company.com
being used by five people makes it difficult to determine who performed an action.
Prefer:
satyendra.admin
rahul.admin
priya.admin
with individual authentication.
Where a technical or business requirement genuinely requires a shared/service account, the organization should define how that account is controlled and monitored.
8. Secure Password Reset and Account Recovery
Authentication security can be undermined by a weak recovery process.
For example:
Forgot Password
↓
Weak identity verification
↓
Attacker resets password
↓
Attacker gains account access
Recovery processes should appropriately verify the requester and protect reset mechanisms.
Consider:
- Identity verification
- MFA recovery
- Recovery codes
- Registered devices
- Administrative reset controls
- Reset notifications
- Logging
- Temporary recovery mechanisms
9. Protect Authentication Information
Authentication information includes:
- Passwords
- PINs
- MFA recovery codes
- API keys
- Tokens
- Private keys
- Certificates
- Authentication secrets
Users should be educated not to:
- Share passwords
- Share MFA codes
- Store passwords insecurely
- Send credentials through email
- Put secrets in source code
- Store credentials in public repositories
10. Protect Service and Machine Authentication
Authentication is not only about human users.
Applications and systems may authenticate to one another.
Examples:
Application → Database
Application → API
CI/CD → Cloud
Application → Storage
Monitoring → Infrastructure
Backup → Storage
These connections may use:
- API keys
- Certificates
- Tokens
- Managed identities
- Service accounts
- Workload identities
These credentials should be appropriately protected and managed.
11. Control API Authentication
APIs frequently provide access to sensitive functionality.
Organizations should consider:
- Strong API authentication
- Token management
- Token expiration
- Secret protection
- API authorization
- Rate limiting
- Logging
- Revocation
- Rotation where appropriate
For example:
A long-lived API token stored in a public repository can potentially provide an attacker with access to a business system.
12. Secure Remote Access
Remote access may include:
- VPN
- Cloud administration
- Remote desktop
- SaaS applications
- Remote support
- Administrative consoles
Authentication should be appropriate for the risk of the remote connection.
For high-risk administrative access, organizations may require:
Individual account + MFA + managed device + restricted network/access conditions
where appropriate.
13. Monitor Authentication Events
Organizations should consider monitoring:
- Successful logins
- Failed logins
- Repeated failed attempts
- MFA failures
- Password resets
- New device authentication
- Privileged authentication
- Suspicious geographic activity
- Unusual authentication patterns
Monitoring should be proportionate to risk.
14. Review Authentication Controls
Authentication requirements should be periodically reviewed.
Review:
- Which systems require MFA?
- Which accounts still use passwords only?
- Which administrator accounts exist?
- Are shared accounts still necessary?
- Are service accounts still required?
- Are authentication mechanisms supported?
- Are old authentication protocols still enabled?
- Have new systems been brought into the authentication standard?
Startup Example
Example: 50-Person SaaS Startup
The startup uses:
- Google Workspace
- GitHub
- AWS
- Slack
- Jira
- CRM
- Accounting software
- HR platform
Initially, employees use individual usernames and passwords.
However:
- MFA is optional
- Some developers use shared admin credentials
- Several service accounts have long-lived tokens
- Cloud administrator access is not centrally reviewed
Improved Model
The startup implements:
SSO where appropriate
↓
MFA
↓
Individual user accounts
↓
Restricted administrator accounts
↓
Secure service credentials
↓
Access reviews
↓
Authentication monitoring
The result is a more controlled authentication environment without requiring a large enterprise IAM team.
Startup Authentication Matrix
| System | User Type | Risk | Authentication |
|---|---|---|---|
| Employees | High | MFA | |
| GitHub | Developers | Critical | MFA |
| AWS | Administrators | Critical | Strong authentication + MFA |
| CRM | Sales/Support | High | MFA/SSO |
| HR | HR | High | MFA/SSO |
| Accounting | Finance | High | MFA |
| Marketing Website | Public users | Variable | Application-specific |
| Production | Administrators | Critical | Strong authentication + controlled privileged access |
Authentication Risk Assessment
A simple risk assessment could look like:
| Risk | Likelihood | Impact | Control |
|---|---|---|---|
| Password phishing | High | High | MFA + awareness |
| Credential reuse | Medium | High | Password manager + MFA |
| Admin account compromise | Medium | Critical | MFA + restricted admin access |
| Shared account misuse | Medium | High | Individual accounts |
| API token exposure | Medium | High | Secret management |
| Weak recovery process | Medium | High | Strong identity verification |
| Service account compromise | Medium | High | Restricted credentials + monitoring |
What Evidence Can an Auditor Ask For?
An auditor may request:
Policies
- Access Control Policy
- Authentication Policy
- Password Policy
- Identity and Access Management Procedure
- Privileged Access Policy
Technical Evidence
- MFA configuration
- SSO configuration
- Identity-provider settings
- Password-policy configuration
- Authentication logs
- Failed-login logs
- Administrative authentication settings
Access Evidence
- User account list
- Privileged account list
- Service account inventory
- Access approvals
- Access reviews
- Termination records
Application Evidence
- Authentication configuration
- API authentication controls
- Session management configuration
- Password hashing configuration
- Authentication testing
Monitoring Evidence
- Login monitoring
- MFA alerts
- Suspicious-login alerts
- Authentication incident records
ISO 27001 Annex A 8.5 Audit Checklist
| Question | Yes/No | Evidence |
|---|---|---|
| Is there an authentication policy or standard? | Policy | |
| Are important systems identified? | System inventory | |
| Are authentication requirements risk-based? | Risk assessment | |
| Is MFA implemented where appropriate? | MFA configuration | |
| Are privileged accounts strongly authenticated? | Admin configuration | |
| Are user accounts individual? | User account list | |
| Are shared accounts controlled? | Account register | |
| Are password requirements defined? | Password policy | |
| Is password storage secure? | Application/security evidence | |
| Is account recovery protected? | Recovery procedure | |
| Are authentication credentials protected? | Procedures | |
| Are service accounts identified? | Service account register | |
| Are API credentials protected? | Secret-management evidence | |
| Are authentication events logged where required? | Logs | |
| Are authentication controls periodically reviewed? | Review records | |
| Are authentication controls removed or updated when no longer required? | Offboarding/change records |
Common Mistakes
1. Treating Passwords as the Entire Authentication Strategy
A password alone may not provide sufficient protection for high-risk systems.
2. Making MFA Optional Everywhere
For critical systems, allowing users to choose whether to enable MFA can leave an important security gap.
3. Using Shared Administrator Accounts
Shared accounts reduce accountability and make investigations more difficult.
4. Ignoring Service Accounts
Organizations often protect human accounts but forget:
- API accounts
- CI/CD accounts
- Application accounts
- Database service accounts
- Automation accounts
These can also be highly privileged.
5. Storing Credentials in Source Code
Source-code repositories should not become credential stores.
This connects directly with:
A.8.4 – Access to Source Code
6. Weak Password Recovery
Strong authentication can be undermined by a weak “Forgot Password” process.
7. No Authentication Review
Organizations sometimes configure MFA once and never review the authentication environment again.
8. Confusing Authentication With Authorization
Successfully logging in does not mean a user should have access to everything.
Authentication answers:
Who are you?
Authorization answers:
What are you allowed to do?
Practical Startup Implementation Model
A startup can implement A.8.5 using:
Identify → Assess → Define → Authenticate → Protect → Monitor → Review → Improve
Identify
List systems, users, applications, APIs, and service accounts requiring authentication.
Assess
Determine authentication risk.
Define
Establish authentication requirements.
Authenticate
Implement appropriate authentication mechanisms.
Protect
Protect passwords, tokens, keys, certificates, and recovery mechanisms.
Monitor
Monitor relevant authentication events.
Review
Periodically review authentication settings and exceptions.
Improve
Update controls based on incidents, new technology, business changes, and risk.
Policy vs. Process vs. Evidence
| Type | Example |
|---|---|
| Policy | Critical systems must use appropriate strong authentication |
| Process | IT provisions MFA during employee onboarding |
| Configuration | MFA enforced through the identity provider |
| Evidence | MFA configuration screenshot/export |
| Record | Periodic authentication-control review |
| Technical Control | Authenticator application/security key |
An auditor is not simply looking for a statement saying:
“We use secure authentication.”
The organization should be able to demonstrate how secure authentication is actually implemented.
Cloud-First Startup Considerations
For a cloud-native startup, authentication may be distributed across:
- Identity provider
- Google Workspace/Microsoft 365
- AWS/Azure/GCP
- GitHub/GitLab
- CRM
- HR systems
- Financial systems
- SaaS applications
- Production applications
A centralized identity approach such as SSO can simplify management where supported.
For example:
Employee
↓
Identity Provider
↓
MFA
↓
SSO
↓
Approved SaaS Applications
This can make employee onboarding, offboarding, authentication enforcement, and access management easier to manage.
However, systems that cannot use centralized SSO still need appropriate authentication controls.
A.8.5 vs A.5.17 – Authentication Information
These controls are closely related.
| Control | Focus |
|---|---|
| A.5.17 | Management and protection of authentication information |
| A.8.5 | Secure authentication mechanisms |
Example
A.5.17: Employees must protect passwords and authentication information.
A.8.5: The company’s systems use appropriate authentication mechanisms such as MFA.
A.8.5 vs A.8.2 – Privileged Access Rights
| Control | Focus |
|---|---|
| A.8.2 | Who receives privileged access |
| A.8.5 | How authentication is securely performed |
A cloud administrator may require privileged access under A.8.2 and MFA under A.8.5.
A.8.5 vs A.8.4 – Access to Source Code
| Control | Focus |
|---|---|
| A.8.4 | Restrict access to source code |
| A.8.5 | Secure authentication used to verify identity |
For example:
A.8.4: Only authorized developers can access the private repository.
A.8.5: Developers must use strong authentication/MFA to access the repository.
A.8.5 vs A.8.3 – Information Access Restriction
| Control | Focus |
|---|---|
| A.8.3 | What information a user can access |
| A.8.5 | How the user’s identity is authenticated |
A user can successfully authenticate but still be denied access to sensitive information.
Questions an Auditor May Ask
1. How do users authenticate?
Explain the organization’s authentication methods.
2. Which systems require MFA?
Provide the applicable system list and configuration.
3. How do you protect administrator accounts?
Demonstrate privileged authentication controls.
4. Do you use shared accounts?
If yes, explain the business justification and controls.
5. How are passwords managed?
Explain password requirements, storage, reset, and protection.
6. How are service accounts managed?
Show the service-account inventory and controls.
7. How are API credentials protected?
Demonstrate secret management and access restrictions.
8. What happens if an employee loses their MFA device?
Show the secure recovery process.
9. How do you monitor authentication events?
Show relevant logs or monitoring.
10. How do you handle authentication after employee termination?
Demonstrate account disabling and credential/access revocation.
Useful Resources
Organizations implementing A.8.5 may maintain:
- Authentication Policy – [Insert Draft Document Link]
- Password Management Policy – [Insert Draft Document Link]
- MFA Standard – [Insert Draft Document Link]
- Identity and Access Management Procedure – [Insert Draft Document Link]
- Privileged Authentication Standard – [Insert Draft Document Link]
- Service Account Management Procedure – [Insert Draft Document Link]
- API Authentication Standard – [Insert Draft Document Link]
- Authentication Risk Assessment – [Insert Draft Document Link]
- Authentication Control Review Checklist – [Insert Draft Document Link]
- User Offboarding Checklist – [Insert Draft Document Link]
Startup-Focused Quick Summary
For most startups, a practical A.8.5 implementation can start with:
1. Individual accounts
Avoid unnecessary shared accounts.
2. MFA
Enable MFA for critical applications and privileged access.
3. Strong passwords
Use appropriate password requirements and secure password management.
4. SSO where practical
Centralize authentication for supported business applications.
5. Protect administrators
Use stronger controls for privileged accounts.
6. Secure service accounts
Do not forget applications, APIs, CI/CD, and automation.
7. Protect recovery
Secure password resets and MFA recovery.
8. Monitor
Review relevant authentication events.
9. Review
Periodically assess authentication controls.
10. Remove
Disable accounts and revoke authentication mechanisms when access is no longer required.
Startup-Focused Final Takeaway
ISO 27001 Annex A 8.5 is fundamentally about making sure that access is granted only after an appropriate level of identity verification.
For a startup, the objective is not to deploy every possible authentication technology.
The objective is to understand:
What systems do we have? Who accesses them? How sensitive are they? What authentication strength is appropriate?
A practical model is:
Identity → Authentication → Authorization → Access → Monitoring
For example:
Employee
↓
Individual Account
↓
Strong Authentication / MFA
↓
Authorization
↓
Approved Application
↓
Activity Monitoring
The most important question for an auditor is therefore not:
“Do you have MFA?”
It is:
“Have you implemented authentication mechanisms appropriate to the risks associated with your users, systems, applications, and information?”
One-Line Summary
ISO 27001 Annex A 8.5 ensures that users, systems, and applications are authenticated using secure and risk-appropriate mechanisms before access is granted.