1. Purpose

The Authentication & Password Policy defines requirements for securely authenticating users, administrators, contractors, service accounts, and other identities accessing organizational systems and information.

The policy aims to ensure that:

• Identities are uniquely attributable where practical.
• Authentication mechanisms are appropriate to risk.
• Passwords are protected throughout their lifecycle.
• Multi-factor authentication (MFA) is used where required.
• Privileged access receives stronger authentication protection.
• Authentication credentials are not shared.
• Authentication failures and suspicious activity are appropriately handled.
• Passwords and authentication secrets are securely stored.
• Authentication requirements are reviewed as technology and risks change.

Core Principle

Verify the identity → Use appropriate authentication → Protect the credential → Limit access → Monitor → Review → Revoke when no longer required.

---

2. Scope

This policy applies to:

• Employees
• Contractors
• Consultants
• Interns
• Temporary personnel
• Third-party users
• Privileged users
• Service accounts
• Application identities
• Cloud identities
• Emergency/break-glass accounts

It covers authentication to:

• Identity Provider/SSO
• Email
• SaaS applications
• AWS/Azure/GCP
• Servers
• Databases
• VPN
• Source-code repositories
• CI/CD platforms
• Security systems
• Business applications
• Customer environments
• Corporate devices
• Remote-access systems

---

3. Authentication Principles

The organization should apply the following principles:

Unique Identity

Users should have individual identities wherever technically possible.

Strong Authentication

Authentication strength should be appropriate to the sensitivity and risk of the resource.

Least Privilege

Authentication does not itself authorize access. Access must also be restricted according to role and business need.

Multi-Factor Authentication

MFA should be used for systems and scenarios where the organization requires stronger authentication.

Credential Protection

Passwords, tokens, keys, recovery codes, and other authentication secrets must be protected from unauthorized disclosure.

No Credential Sharing

Users must not share passwords, MFA codes, tokens, or other authentication credentials.

Accountability

Authentication activity should be attributable to the relevant identity wherever practical.

---

4. Authentication Methods

Depending on the system and risk, authentication may use:

• Password
• Password + MFA
• SSO
• Hardware security key
• Passkey
• Certificate
• Client certificate
• Biometric authentication
• Federated identity
• Cloud IAM role
• Workload identity
• Short-lived token
• API authentication
• Other approved mechanisms

The organization should select authentication methods based on:

• Information classification
• System criticality
• Privilege level
• Threat environment
• Technical capability
• Business requirements
• Regulatory/contractual requirements

---

5. Password Requirements

Where passwords are used, users should create passwords that are difficult to guess and should follow the organization’s configured password requirements.

Passwords should:

• Be unique to the organizational account.
• Not be reused across unrelated services.
• Not be shared with another person.
• Not be stored in plain text.
• Not be written in unsecured locations.
• Not be included in source code.
• Not be sent through ordinary email or chat.
• Not be based on easily available personal information.
• Not be predictable or commonly used.

Organizations should use technically enforced password controls where supported.

---

6. Password Length and Complexity

The organization should define password requirements based on its authentication technology and security risk.

Where passwords are permitted, the organization may define requirements such as:

• Minimum password length
• Blocklists for commonly used passwords
• Protection against breached/compromised passwords
• Password history where appropriate
• Account lockout or throttling
• Secure password reset
• Appropriate session controls

A password policy should not rely solely on arbitrary complexity rules if the organization’s authentication platform provides stronger controls such as password blocklists, MFA, throttling, or phishing-resistant authentication.

---

7. Password Managers

Approved password-management solutions should be used where appropriate.

Users should:

• Store organizational passwords only in approved password managers.
• Use unique passwords for important systems.
• Protect the password-manager account with strong authentication.
• Never export or share password databases through unapproved channels.
• Never store organizational passwords in browsers or applications unless approved by the organization.

The organization should define which password managers are approved.

---

8. Multi-Factor Authentication (MFA)

MFA should be enabled for systems and identities where required by organizational risk, policy, contractual, regulatory, or technical requirements.

MFA may use:

• Authenticator application
• Hardware security key
• Passkey
• Approved biometric factor
• Smart card
• Other approved authentication factor

MFA should be prioritized for:

• Privileged accounts
• Cloud administration
• Identity-management systems
• Email
• Remote access
• Security systems
• Production environments
• Systems containing sensitive information
• Critical SaaS applications

---

9. Phishing-Resistant Authentication

Where appropriate and technically feasible, the organization should consider phishing-resistant authentication mechanisms such as:

• Passkeys
• Hardware security keys
• FIDO2/WebAuthn-based authentication
• Other approved phishing-resistant mechanisms

These mechanisms may be particularly appropriate for privileged and high-risk accounts.

---

10. MFA Fatigue and Push Approval

Users must not approve an unexpected MFA request.

If a user receives:

• Unexpected MFA prompts
• Repeated authentication requests
• Unknown login notifications
• Unrecognized security alerts

the user should:

Stop → Do Not Approve → Report → Investigate

Repeated MFA prompts may indicate attempted credential compromise.

---

11. Privileged Account Authentication

Privileged identities should receive stronger authentication protection appropriate to their risk.

Requirements may include:

• MFA
• Dedicated administrative identity
• SSO
• Strong authentication
• Restricted login locations
• Conditional access
• Privileged access management
• Short-lived access
• Additional approval
• Logging and monitoring

Privileged identities should not rely on shared administrator passwords where individual authentication is technically feasible.

---

12. AWS Authentication

For AWS environments, the organization should use centralized identity and role-based access mechanisms where practical.

Example:

User → Identity Provider → MFA → AWS Role → Required Resources

Recommended practices include:

• Protect the AWS root account.
• Avoid routine use of root credentials.
• Avoid shared administrator credentials.
• Use roles for human access where practical.
• Use temporary credentials where appropriate.
• Enable MFA for appropriate privileged identities.
• Restrict permissions using least privilege.
• Log relevant authentication and administrative activity.
• Review privileged access periodically.

---

13. Service Account Authentication

Service accounts may use authentication methods such as:

• Workload identity
• IAM roles
• Managed identities
• Certificates
• API tokens
• Secrets
• Other approved mechanisms

Where possible, prefer short-lived or identity-based mechanisms over long-lived static credentials.

Service account credentials must not be stored in:

• Source code
• Git repositories
• Spreadsheets
• Email
• Chat
• Unsecured configuration files
• Documentation

Service accounts should be recorded in the Service Account Register.

---

14. API Keys and Tokens

API keys, access tokens, SSH keys, certificates, and similar credentials must be treated as authentication secrets.

Requirements include:

• Store securely.
• Limit permissions.
• Limit scope.
• Set expiry where supported.
• Rotate where required.
• Do not expose in source code.
• Do not commit secrets to public repositories.
• Revoke when no longer required.
• Rotate when compromise is suspected.

---

15. Password Storage

Systems must not store passwords in plain text.

Where the organization develops or operates authentication systems, passwords should be protected using appropriate password-hashing mechanisms and secure implementation practices.

Applications should use established identity/authentication technologies rather than creating custom password-management mechanisms without appropriate security review.

---

16. Password Transmission

Passwords must not be transmitted through insecure channels.

Users must not send passwords through:

• Ordinary email
• Chat messages
• SMS where inappropriate
• Tickets
• Spreadsheets
• Documents
• Source code
• Unapproved file-sharing systems

Where credentials must be provisioned or transferred, an approved secure mechanism should be used.

---

17. Password Reset

Password-reset processes must verify the identity of the requester before allowing credentials to be changed.

Reset mechanisms should:

• Require appropriate identity verification.
• Use secure recovery mechanisms.
• Avoid revealing passwords.
• Prevent unauthorized reset.
• Log significant reset activity where appropriate.
• Require MFA re-enrollment where necessary.
• Address compromised authentication factors.

Support personnel must not disclose user passwords.

---

18. Forgotten Passwords

Users should use the organization’s approved password-reset process.

Users must not:

• Ask another employee for their password.
• Use another employee’s credentials.
• Bypass authentication controls.
• Create an unofficial shared account.

If the approved recovery mechanism does not work, the issue should be escalated to IT/security support.

---

19. Account Lockout and Authentication Throttling

Authentication systems should use appropriate protections against repeated failed authentication attempts.

Controls may include:

• Rate limiting
• Authentication throttling
• Temporary lockout
• Risk-based authentication
• CAPTCHA or equivalent controls where appropriate
• Automated detection
• Alerting

The implementation should balance security with the risk of denial-of-service through account lockout.

---

20. Failed Authentication Monitoring

Where technically feasible, systems should monitor relevant authentication events.

Examples include:

• Repeated failed login attempts
• Successful login after multiple failures
• Login from unusual locations
• Impossible-travel indicators
• Unusual administrative login
• Authentication from unexpected devices
• Multiple MFA failures
• Unexpected password reset
• New authentication factor registration

Significant suspicious activity should be investigated according to the Incident Management Procedure.

---

21. Authentication Session Management

Applications and systems should implement appropriate session controls based on risk.

Controls may include:

• Session timeout
• Automatic screen lock
• Re-authentication for sensitive actions
• Session termination after logout
• Token expiration
• Secure session handling
• Device/session revocation

Privileged and high-risk sessions may require stronger controls.

---

22. Corporate Device Authentication

Corporate devices should use appropriate authentication controls.

Examples:

• Strong device password/PIN
• Biometric authentication where approved
• Automatic screen lock
• Disk encryption
• Device management
• MFA for sensitive services
• Endpoint security

Users must not leave authenticated devices unattended without appropriate protection.

---

23. Remote Authentication

Remote access should use approved authentication mechanisms.

Where applicable:

• MFA
• SSO
• VPN or approved secure remote access
• Device security controls
• Conditional access
• Least privilege
• Session controls
• Logging

Public or untrusted networks should not be treated as trusted merely because the user has authenticated.

---

24. Contractor Authentication

Contractor accounts should:

• Use identifiable accounts.
• Use MFA where required.
• Have limited access.
• Have defined expiry where practical.
• Use approved authentication mechanisms.
• Be periodically reviewed.
• Be revoked when the engagement ends.

Contractors must not share organizational credentials.

Refer to the Contractor Account Procedure.

---

25. Third-Party Authentication

Third-party users should authenticate using approved mechanisms.

Where possible:

• Use individual accounts.
• Use federation/SSO.
• Use MFA.
• Restrict permissions.
• Set expiry.
• Monitor relevant activity.
• Review periodically.
• Revoke when access is no longer required.

Shared third-party credentials should be avoided where individual accountability is technically possible.

---

26. Emergency / Break-Glass Authentication

Emergency identities should be tightly controlled.

Requirements may include:

• Restricted access
• Strong credential protection
• Limited authorized users
• Secure storage
• Monitoring where possible
• Periodic testing
• Activity review after use
• Credential rotation where appropriate

Emergency authentication should not replace normal access-control processes.

---

27. Authentication Factor Changes

Changes to authentication factors should be protected.

Examples:

• New phone
• New authenticator
• New security key
• Lost security key
• MFA reset
• Recovery method change
• Device replacement

Where risk warrants, identity verification should be performed before changing authentication factors.

---

28. Lost or Compromised Authentication Device

If a device or authentication factor is lost or suspected to be compromised:

1. Report immediately.
2. Assess the affected identity.
3. Revoke the authentication factor/session where possible.
4. Reset credentials if required.
5. Re-enroll MFA.
6. Review recent authentication activity.
7. Assess whether unauthorized access occurred.
8. Escalate as a security incident where appropriate.
9. Record the action.

---

29. Password/Authentication Compromise

If a password or authentication credential is suspected to be compromised:

Report → Contain → Reset/Revoke → Terminate Sessions → Review Activity → Investigate → Record

Depending on the risk, actions may include:

• Password reset
• Token revocation
• API-key rotation
• SSH-key replacement
• Certificate replacement
• MFA re-enrollment
• Session termination
• Privilege reduction
• Incident escalation

---

30. Joiner Authentication

During onboarding:

• Create approved identity.
• Configure authentication.
• Enroll MFA where required.
• Provide secure initial credential setup.
• Verify authentication.
• Provide only approved access.
• Record completion.

Initial passwords or activation information should be delivered using approved secure methods.

---

31. Mover Authentication

When a user changes roles:

• Review existing identity.
• Review authentication requirements.
• Review privileged access.
• Remove unnecessary access.
• Add approved new access.
• Reassess MFA/strong authentication requirements.
• Update identity records.

---

32. Leaver Authentication

When a user leaves:

• Disable identity.
• Terminate sessions where appropriate.
• Revoke authentication tokens.
• Revoke MFA sessions/factors where applicable.
• Remove privileged roles.
• Revoke VPN access.
• Remove SaaS access.
• Address API/SSH credentials associated with the user.
• Verify revocation.

Refer to the Access Revocation Checklist and JML Procedure.

---

33. Authentication Exceptions

Exceptions may include:

• Legacy applications that cannot support MFA.
• Technical limitations.
• Emergency operational requirements.
• Customer-mandated authentication arrangements.
• Service accounts that cannot use human authentication mechanisms.

Each exception should document:

Field	Description
Exception ID	Unique identifier
System/Identity	Affected system
Requirement	Authentication requirement
Exception	What cannot be implemented
Reason	Technical/business reason
Risk	Associated risk
Compensating Control	Additional protection
Owner	Responsible person
Approval	Authorized approval
Expiry/Review	Review date
Status	Open/Closed

---

34. Authentication for Sensitive Information

Authentication requirements should reflect information sensitivity.

Example:

Information/System	Classification/Risk	Example Authentication
Public Website	Public	Standard administrative authentication
Internal Collaboration	Internal	SSO + appropriate authentication
Customer Data	Confidential	Strong authentication/MFA where required
Production Administration	High	MFA + privileged controls
Production Credentials	Restricted	Strongly restricted privileged authentication

These are examples; actual requirements should be based on organizational risk and system capabilities.

---

35. Password and Authentication Review

The organization should periodically review:

• Password policy configuration
• MFA coverage
• Privileged-account MFA
• Dormant identities
• Shared accounts
• Authentication exceptions
• Password-reset mechanisms
• Authentication logs
• Compromised credentials
• Service-account credentials
• API keys/tokens
• Authentication-factor enrollment
• Leaver account removal

---

36. Authentication Evidence

Evidence may include:

• Identity Register
• Authentication configuration
• MFA configuration
• SSO configuration
• IAM configuration
• Password-policy settings
• Access-control reports
• Authentication logs
• MFA enrollment reports
• Password-reset records
• Credential-rotation records
• API-key/token records
• Privileged-access reviews
• Access-revocation records
• Authentication exception register
• Security incident records

Actual passwords, tokens, API keys, private keys, or recovery codes must never be stored as audit evidence.

---

37. Roles and Responsibilities

Role	Responsibility
Employees/Users	Protect credentials and use authentication securely
Managers	Ensure access and authentication requirements match roles
IT/IAM	Configure authentication controls
Security/ISMS	Define security requirements and monitor effectiveness
System Owners	Implement appropriate system authentication
Application Owners	Ensure application authentication is appropriately configured
Cloud Team	Manage cloud authentication and privileged identities
HR/People	Notify joiner/mover/leaver events
Contractors	Protect assigned credentials
Internal Audit	Independently verify control effectiveness
Management	Approve significant authentication risks/exceptions

---

38. User Responsibilities

Users must:

• Keep passwords confidential.
• Use approved authentication mechanisms.
• Use MFA where required.
• Never approve unexpected MFA prompts.
• Never share authentication credentials.
• Report suspected compromise immediately.
• Lock devices when unattended.
• Follow approved password-reset procedures.
• Report lost authentication devices.
• Avoid storing organizational credentials in unapproved locations.

---

39. Password and Authentication Training

Security awareness training should explain:

• Password security
• Password-manager usage
• MFA
• MFA fatigue
• Phishing
• Credential theft
• Fake login pages
• Password reuse
• Credential sharing
• Secure password reset
• Reporting compromised credentials
• Secure use of cloud/SaaS systems

A simple employee rule is:

STOP → CHECK → VERIFY → AUTHENTICATE → REPORT

---

40. AWS SaaS Startup Example

A SaaS startup uses AWS, Microsoft 365, GitHub, Jira, and an identity provider.

Normal User

Identity Provider → SSO + MFA → Approved SaaS Applications

Developer

SSO + MFA → GitHub → Developer Role

AWS Administrator

SSO + MFA → Privileged AWS Role → Production Account

Application

AWS Workload Identity → Limited IAM Role → Required Resources

Contractor

Named Identity → MFA → Limited Access → Expiry Date

This model reduces reliance on shared passwords and provides stronger identity accountability.

---

41. Startup-Friendly Minimum Controls

A startup can begin with:

Identity

• Unique user accounts
• Centralized identity provider where practical

Authentication

• MFA for important/high-risk systems
• Strong authentication for privileged users
• Secure password management

Access

• Least privilege
• Role-based access
• Separate privileged access where appropriate

Credentials

• Approved password manager
• Secure secrets management
• No credentials in source code

Lifecycle

• Joiner controls
• Mover access review
• Leaver revocation

Monitoring

• Authentication logging where practical
• Investigation of suspicious authentication activity

Review

• Periodic identity and privileged-access review

---

42. Common Mistakes

Avoid:

• Reusing passwords across systems.
• Sharing administrator passwords.
• Using shared accounts when individual accounts are available.
• No MFA for privileged accounts.
• Storing passwords in spreadsheets.
• Storing API keys in source code.
• Sending passwords through email/chat.
• Leaving former employees’ accounts active.
• Forgetting contractor account expiry.
• Ignoring service-account credentials.
• Treating password rotation alone as the primary security control.
• Approving unexpected MFA requests.
• Failing to investigate suspicious authentication activity.
• Using the same authentication strength for every system regardless of risk.

---

43. Relationship with Other ISMS Documents

This policy connects with:

• Identity Management Policy
• User Account Management Procedure
• Identity Register
• Contractor Account Procedure
• Joiner-Mover-Leaver Procedure
• Privileged Identity Management Procedure
• Privileged Access Register
• Service Account Register
• Access Control Policy
• Access Control Matrix
• Access Review Report
• Identity Review Checklist
• Access Revocation Checklist
• Remote Working Policy
• BYOD Policy
• Employee IT Usage Policy
• Security Awareness Training
• Incident Response Plan
• Data Handling Guidelines
• Risk Register

Control Chain

Identity

→ Authentication

→ Authorization

→ Access

→ Monitoring

→ Review

→ Revocation

---

44. ISO 27001 Connection

This policy supports applicable ISO/IEC 27001 requirements and controls relating to:

• Identity management
• Authentication information
• Authentication mechanisms
• Access rights
• Access restriction
• Privileged access
• Secure authentication
• Logging and monitoring
• Personnel lifecycle
• Supplier/third-party access
• Incident management

The exact controls applicable to the organization should be determined through the organization’s risk assessment and Statement of Applicability (SoA).

---

45. Quick Audit Checklist

Identity

• Unique identities used where practical
• Identity owners identified
• Shared accounts controlled
• Privileged identities identified
• Service identities identified

Passwords

• Password requirements configured
• Common/compromised passwords addressed where supported
• Passwords not shared
• Passwords not stored in plain text
• Approved password manager available where appropriate

MFA

• MFA requirements defined
• Privileged accounts protected
• Important SaaS systems protected
• Cloud administration protected
• Remote access protected
• MFA recovery process controlled

Authentication

• SSO used where appropriate
• Strong authentication used for high-risk systems
• Authentication failures monitored where appropriate
• Session controls implemented
• Authentication-factor changes controlled

Credentials

• API keys protected
• Tokens protected
• SSH keys protected
• Certificates controlled
• Secrets not stored in source code
• Credential rotation addressed

Lifecycle

• Joiner authentication configured
• Mover access reassessed
• Leaver authentication revoked
• Contractor accounts reviewed
• Dormant identities reviewed

Security

• Compromised credentials can be revoked
• Lost authentication devices can be handled
• Suspicious MFA activity is reported
• Authentication exceptions documented
• Evidence retained

---

46. Final Audit Trail

For an important identity, the organization should be able to demonstrate:

Who is the user?

→ How was the identity established?

→ How is the user authenticated?

→ Is MFA required and enabled?

→ What access does the identity have?

→ Is stronger authentication required because of the privilege or information accessed?

→ How are credentials protected?

→ Are authentication events appropriately monitored?

→ What happens if the credential is compromised?

→ What happens when the user’s role changes?

→ What happens when the user leaves?

→ Is evidence available?

Final Principle

Authentication should establish that the right identity is accessing the system, while access controls ensure that the identity can do only what it is authorized to do. Protect the authentication factor, use stronger authentication for higher-risk access, monitor appropriately, and revoke credentials when they are no longer required.