ISO 27001 A.8.5: Secure Authentication

Quick Reference: A.8.5 in 60 Seconds

One-Sentence Summary: A.8.5 ensures that every person, application, and device attempting to access your systems can prove who they are, using methods strong enough for the risk of what they're accessing.

What the Standard Actually Requires

Figure · Process

What A.8.5 asks you to do

ISO 27001:2022 A.8.5 Text

ISO 27001:2022 Annex A 8.5 asks organizations to implement secure authentication technologies and procedures based on access restrictions and the access control policy.

This single sentence is deceptively simple but contains three critical requirements:

1. "Technologies", You must use appropriate technical solutions (not just passwords)
2. "Procedures", You must have documented processes for how authentication works
3. "Based on information access restrictions and the organization's access control policy", Authentication strength must match the sensitivity of what's being accessed

ISO 27002:2022 Implementation Guidance (Section 8.5)

ISO 27002 provides 7 implementation guidelines that expand the control into actionable direction:

1. Authentication strength should match risk, Not all systems need the same authentication. A public website and a financial database have fundamentally different requirements. Risk-based authentication is the cornerstone of modern identity security.

2. Multi-factor authentication (MFA) should be used for sensitive access, When the risk is high, one factor is never enough. The standard implicitly expects MFA for anything beyond low-sensitivity systems.

3. Authentication information should be protected, Credentials must be encrypted in transit and at rest. No cleartext storage or transmission. This includes passwords, tokens, certificates, and biometric templates.

4. Secure log-on procedures should be implemented, Minimal disclosure, generic errors, brute-force protection, and secure design patterns for all login interfaces.

5. Session management should be implemented, Timeouts, maximum durations, re-authentication for sensitive operations, and secure token handling.

6. Non-human authentication should be secured, Service accounts, APIs, bots, and IoT devices need the same rigor as human accounts. Often overlooked, this is where many breaches originate.

7. Authentication events should be logged and monitored, Every success and failure must be captured, retained, and analyzed for anomalies.

What Auditors Actually Check

Why A.8.5 Matters: The Business Case

The Credential Crisis

Authentication is the front door to every system, every database, every customer record. Yet it remains the most attacked vector:

The Indian Context

India's rapid digital transformation makes secure authentication particularly critical:

• UPI transactions: 12+ billion per month, every transaction requires authentication
• Digital India: 1.3 billion Aadhaar-linked identities, authentication at national scale
• Startups: 100,000+ startups, many lack mature authentication practices
• Remote work: 70% of Indian tech workers work remotely at least part-time, remote access authentication is essential
• CERT-In reports: Authentication-related incidents account for 35% of reported cybersecurity incidents in India

Business Impact of Weak Authentication

Scope and Applicability

What A.8.5 Covers

A.8.5 applies to all authentication mechanisms across the organization:

What A.8.5 Does NOT Cover

Key Definitions and Concepts

Authentication vs. Authorization vs. Identity

Authentication Factors

Key Terms

Relationship to Other Controls

A.8.5 Ecosystem Map

                    ┌─────────────────────────────────────┐
                    │     A.5.15 — ACCESS CONTROL          │
                    │    (What can you access?)             │
                    └─────────────────┬───────────────────┘
                                      │
                    ┌─────────────────┴───────────────────┐
                    │     A.8.5 — SECURE AUTHENTICATION    │
                    │    (Who are you? Prove it.)           │
                    └─────────────────┬───────────────────┘
                                      │
        ┌─────────────────────────────┼─────────────────────────────┐
        │                             │                             │
   ┌────┴────┐                  ┌─────┴─────┐                ┌──────┴──────┐
   │ A.5.16  │                  │ A.5.17    │                │  A.8.2      │
   │ Identity│                  │ Auth Info │                │ Privileged  │
   │ Mgmt    │                  │ Mgmt      │                │ Access      │
   │(Who are  │                  │(Keys,    │                │(Admin      │
   │ you?)    │                  │ passwords)│                │ accounts)   │
   └────┬────┘                  └─────┬─────┘                └──────┬──────┘
        │                             │                             │
   ┌────┴────┐                  ┌─────┴─────┐                ┌──────┴──────┐
   │ A.8.15  │                  │ A.8.16    │                │  A.8.4      │
   │ Logging │                  │ Monitoring│                │  Removal    │
   │(Record   │                  │(Detect   │                │  of Access  │
   │ events)  │                  │ anomalies)│                │  Rights     │
   └─────────┘                  └───────────┘                └─────────────┘

Detailed Control Relationships

The 8 Pillars of Secure Authentication

Think of A.8.5 as 8 interlocking pillars. Weakness in any one pillar compromises the entire structure. Each pillar must be implemented with equal rigor.

                    ┌─────────────────────────────────────┐
                    │     PILLAR 1: AUTHENTICATION         │
                    │         STANDARD & POLICY             │
                    │   (The foundation — everything       │
                    │    references this document)          │
                    └─────────────────┬───────────────────┘
                                      │
        ┌─────────────────────────────┼─────────────────────────────┐
        │                             │                             │
   ┌────┴────┐                  ┌─────┴─────┐                ┌──────┴──────┐
   │ PILLAR 2│                  │ PILLAR 3  │                │  PILLAR 4   │
   │  RISK-  │                  │ PASSWORD  │                │    MFA      │
   │  BASED  │                  │  POLICY   │                │  & FACTORS  │
   │  MODEL  │                  │           │                │             │
   └────┬────┘                  └─────┬─────┘                └──────┬──────┘
        │                             │                             │
   ┌────┴────┐                  ┌─────┴─────┐                ┌──────┴──────┐
   │ PILLAR 5│                  │ PILLAR 6  │                │  PILLAR 7   │
   │ SESSION │                  │  SECURE   │                │  NON-HUMAN  │
   │   MGMT  │                  │ LOG-ON    │                │     AUTH     │
   │         │                  │  DESIGN   │                │             │
   └────┬────┘                  └─────┬─────┘                └──────┬──────┘
        │                             │                             │
        └─────────────────────────────┼─────────────────────────────┘
                                      │
                    ┌─────────────────┴───────────────────┐
                    │     PILLAR 8: LOGGING & MONITORING │
                    │   (The nervous system — detects     │
                    │    breaches and provides evidence)  │
                    └─────────────────────────────────────┘

Pillar 1: Authentication Standard & Policy

The foundation document that defines your organization's approach to authentication. Every other pillar references this.

Required elements:

• Authentication principles (risk-based, MFA mandate, passwordless target)
• Factor requirements by system classification
• Password policy (length, complexity, rotation, storage)
• MFA policy (enforcement, exceptions, methods)
• Session management (timeouts, concurrent sessions, re-authentication)
• Non-human authentication (service accounts, APIs, IoT)
• Logging and monitoring requirements
• Exception process and risk acceptance
• Roles and responsibilities
• Review and update cycle (annual minimum)

Pillar 2: Risk-Based Model

Not all systems need the same authentication strength. Assign Authentication Assurance Levels (AAL) based on risk.

Pillar 3: Password Policy

Modern, evidence-based password requirements that prioritize length over complexity and eliminate harmful practices like forced rotation.

Pillar 4: MFA & Factors

Multi-factor authentication is the single most effective control against credential attacks. Implement it everywhere feasible.

Pillar 5: Session Management

Authentication is not a one-time event. Sessions must be actively managed with timeouts, re-authentication, and secure token handling.

Pillar 6: Secure Log-On Design

Login interfaces must be designed to resist reconnaissance, enumeration, and brute force attacks. Generic errors, rate limiting, and minimal disclosure are essential.

Pillar 7: Non-Human Authentication

Service accounts, APIs, bots, and IoT devices now outnumber human accounts. They need the same, often stronger, authentication controls.

Pillar 8: Logging & Monitoring

Every authentication event must be logged, retained, and monitored. This is your evidence for audits and your detection mechanism for attacks.

Risk-Based Authentication Model

The most important concept in A.8.5: not all systems need the same authentication strength. Applying the same authentication to every system is either wasteful (over-protecting low-risk systems) or dangerous (under-protecting high-risk ones).

The Authentication Assurance Levels (AAL)

(Based on NIST SP 800-63B Authenticator Assurance Levels, aligned with ISO 27001 risk-based approach)

How to Assign Authentication Levels

Step 1: Classify Your Information (A.5.12)

Map your information classification directly to authentication requirements:

Step 2: Assess Additional Risk Factors

Add +1 to your required level if any of these apply:

• System is internet-facing (public IP, no VPN required)
• System allows remote access (VPN, RDP, SSH from outside)
• System handles financial transactions (payments, payroll, accounting)
• System contains PII, health data, or payment card data
• System is privileged/admin access (domain admin, root, cloud admin)
• System has no compensating controls (no WAF, no network segmentation)
• System is accessed by third parties (contractors, vendors, partners)
• System is a single point of failure (no redundancy, no backup)

Step 3: Document the System-by-System Authentication Matrix

Risk-Based Authentication in Practice

Example: Adaptive Authentication Flow

User attempts to log in
         │
         ▼
┌─────────────────────────┐
│ 1. Evaluate risk signals │
│    • Location (known? )  │
│    • Device (managed? )  │
│    • Time (business hrs? )│
│    • Behavior (anomaly? ) │
│    • Network (corporate? ) │
└─────────────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 2. Calculate risk score  │
│    0-20: Low risk        │
│    21-50: Medium risk    │
│    51-80: High risk      │
│    81-100: Critical risk │
└─────────────────────────┘
         │
         ▼
┌─────────────────────────┐
│ 3. Apply policy          │
│    Low: Standard auth    │
│    Medium: + TOTP        │
│    High: + hardware key  │
│    Critical: Block + alert│
└─────────────────────────┘

Real-World Risk Signals:

Password Policy: The Modern Standard

What NIST SP 800-63B Says (And Why ISO 27001 Aligns)

The old password rules have been scientifically disproven. NIST SP 800-63B (2017) and subsequent research have fundamentally changed password policy recommendations. Here's the evidence-based approach:

Active Directory / Entra ID Configuration

Group Policy Settings (Windows Active Directory):

Entra ID (Azure AD) Settings:

Okta Settings:

Password Hashing Best Practices

Multi-Factor Authentication (MFA) Deep Dive

The MFA Factor Hierarchy (Strongest to Weakest)

NIST SP 800-63B Authenticator Assurance Levels (AAL)

MFA Enforcement Strategy: The 4-Phase Rollout

Phase 1: Immediate (Week 1), Critical Accounts

• Enable MFA for all admin accounts (AWS root, Azure AD Global Admin, Domain Admin, Google Super Admin)
• Enable MFA for all cloud console access (AWS Management Console, Azure Portal, GCP Console)
• Enable MFA for VPN access (all remote access methods)
• Enable MFA for remote desktop (RDP, SSH jump boxes, VDI)
• Enable MFA for code repository admin access (GitHub Org Admin, GitLab Admin)
• Enable MFA for financial system admin access (ERP, accounting, payroll)
• Document all exceptions with risk acceptance forms

Phase 2: Short Term (Weeks 2–4), Workforce Expansion

• Enable MFA for all SaaS apps (Google Workspace, Microsoft 365, Salesforce, Slack, Jira)
• Enable MFA for all Git/code repositories (GitHub, GitLab, Bitbucket, all users, not just admins)
• Enable MFA for financial systems (ERP, accounting, all users)
• Enable MFA for HR systems (HRMS, payroll, benefits)
• Enable MFA for customer support tools (Zendesk, Freshdesk, Intercom)
• Target: 80% workforce MFA enrollment by end of Week 4

Phase 3: Medium Term (Weeks 5–8), Complete Coverage

• Enable MFA for all customer-facing systems (if applicable, B2B portals, customer dashboards)
• Enable MFA for all third-party contractor access (time-limited, scoped)
• Enable MFA for CI/CD pipeline access (GitHub Actions, Jenkins, GitLab CI)
• Enable MFA for database admin tools (pgAdmin, MySQL Workbench, DataGrip)
• Enable MFA for monitoring and alerting tools (Datadog, Grafana, PagerDuty)
• Target: 95% workforce MFA enrollment by end of Week 8

Phase 4: Long Term (Weeks 9–12), Optimization

• Enable MFA for ALL users on ALL systems (zero exceptions except documented)
• Migrate from SMS/TOTP to FIDO2/passkeys for all admin accounts
• Implement passwordless for low-risk systems (internal wiki, non-sensitive tools)
• Implement risk-based step-up (unusual location = additional factor)
• Implement conditional access (managed device + known location = standard auth)
• Target: 100% MFA enrollment, 50% passwordless adoption

MFA Exceptions (Documented Only)

Some systems genuinely cannot support MFA. Document these with formal exceptions:

Rule: Every exception must have:

1. Risk acceptance form (CISO or higher approved)
2. Compensating control (at least one)
3. Quarterly review date
4. Risk acceptance ID for tracking
5. Retirement plan (how to eliminate the exception)

MFA Methods by Use Case

MFA Fatigue and Number Matching

The Problem: Attackers bombard users with push notifications until they accept one ("MFA fatigue" or "MFA bombing"). The Uber breach (2022) was caused by this exact technique.

Defenses:

FIDO2/WebAuthn Implementation Guide

FIDO2 is the gold standard for authentication. It is phishing-resistant by design because the credential is bound to the website domain.

How FIDO2 Works:

1. User registers a FIDO2 authenticator (hardware key, phone, laptop TPM)
2. During registration, the authenticator creates a public/private key pair
3. The private key NEVER leaves the authenticator
4. During authentication, the website sends a challenge
5. The authenticator signs the challenge with the private key
6. The website verifies the signature with the stored public key
7. If the website is a fake phishing site (wrong domain), the authenticator will refuse

Implementation Steps:

1. Enable in IdP: Okta (Okta FastPass), Azure AD (FIDO2 security key), Google Workspace (FIDO2)
2. Enable in applications: Use WebAuthn API for custom apps
3. Distribute hardware keys: Order YubiKey 5 NFC or Bio series for admin accounts
4. Train users: Provide setup guides for Windows Hello, Apple Touch ID, Android fingerprint
5. Monitor adoption: Track FIDO2 enrollment percentage
6. Target: 100% admin accounts on FIDO2 within 3 months

Recommended Hardware Keys:

Passwordless & Passkey Authentication

What Are Passkeys?

Passkeys are FIDO2/WebAuthn credentials that replace passwords entirely. They represent the future of authentication, eliminating the weakest link (passwords) while improving user experience.

Key characteristics:

• Phishing-resistant, Bound to the website domain, cannot be tricked by fake sites. The credential only works for the exact domain it was registered for.
• No shared secrets, Private key never leaves the device. The server only stores a public key, which is useless to attackers.
• Cross-device, Sync via Google Password Manager, Apple iCloud Keychain, 1Password, or Dashlane. Use your phone to authenticate on your laptop.
• User-friendly, Biometric (fingerprint/face) or PIN unlock. No passwords to remember, no passwords to forget.
• Breach-proof, If the server is breached, attackers only get public keys, which cannot be used to authenticate.
• No credential reuse, Each passkey is unique per site. No risk of the same password being used across multiple services.

Passkey vs. Password Comparison

Passkey Implementation Roadmap

Phase 1: Enable (Month 1)

• Enable passkey support in your IdP (Okta, Azure AD, Google Workspace)
• Enable passkey support in your customer-facing apps (WebAuthn API)
• Communicate to users: "You can now use passkeys instead of passwords"
• Provide passkey setup guides for iOS, Android, Windows, macOS
• Train IT help desk on passkey troubleshooting
• Target: 10% passkey adoption

Phase 2: Encourage (Months 2–3)

• Make passkey the default option during enrollment
• Provide passkey setup guides for all platforms
• Offer incentives: "Set up a passkey, get a coffee gift card" (optional)
• Add passkey to security awareness training
• Share success stories: "No more password resets!"
• Target: 25% passkey adoption

Phase 3: Push (Months 4–6)

• Require passkey for new accounts (make it the default)
• Require passkey for admin accounts (hardware key or platform authenticator)
• Send reminders to users still on passwords: "Your account is more secure with a passkey"
• Disable password-based authentication for low-risk systems (pilot)
• Target: 50% passkey adoption

Phase 4: Sunset (Months 6–12)

• Disable password-based authentication for low-risk systems (all)
• Disable password-based authentication for medium-risk systems
• Retain password as fallback only for high-risk systems (with strong MFA)
• Target: 80% passkey adoption, password only for legacy exceptions
• Plan for full password elimination by Month 18

Passkey Platform Support (2026)

Break-Glass with Passkeys

Challenge: What happens if the IdP is down and you need emergency access?

Solution: Offline hardware keys

• Store 2–3 hardware keys in a physical safe (separate locations)
• Register them as break-glass authenticators
• Test quarterly (physical retrieval + login test)
• Auto-expire break-glass sessions after 24 hours
• Require CISO approval for any break-glass use
• Document all break-glass usage in incident log

Single Sign-On (SSO) & Identity Providers

SSO Architecture Decision: SAML vs. OIDC

Singahi Recommendation: Use OIDC for all new applications. Maintain SAML only for legacy apps that cannot be migrated. Plan SAML-to-OIDC migration over 2–3 years.

Centralized IdP Strategy

The Goal: One identity provider, one source of truth, one place to enforce policy. This is the "single pane of glass" for identity.

SSO Implementation Checklist

• All SaaS apps integrated with IdP (zero standalone authentication)
• MFA enforced at IdP level, not per-app (consistent policy, no gaps)
• Session timeout enforced at IdP (30 minutes idle, 8 hours maximum)
• Conditional access rules configured (location, device, risk, time)
• User provisioning/deprovisioning automated (SCIM protocol)
• Break-glass accounts documented (emergency access without SSO)
• IdP logs forwarded to SIEM (centralized visibility)
• IdP configuration reviewed quarterly (access reviews, policy updates)
• IdP high availability configured (no single point of failure)
• IdP backup and recovery tested annually
• IdP administrator roles segregated (no single admin has full control)
• IdP certificate rotation automated (SAML signing, OIDC discovery)

SCIM Provisioning

SCIM (System for Cross-domain Identity Management) automates user lifecycle:

Automated Actions:

• New hire → IdP creates account → SCIM provisions to all apps
• Role change → IdP updates groups → SCIM updates app permissions
• Termination → IdP disables account → SCIM deprovisions from all apps
• Leave → IdP suspends → SCIM suspends app access

Benefits:

• Eliminates manual account creation/deletion errors
• Ensures access is removed within hours, not days
• Reduces help desk tickets by 60%
• Improves audit compliance (provable access removal)

Break-Glass and Emergency Access

When the IdP fails, you still need access to critical systems. Plan for this:

Non-Human Authentication (APIs, Service Accounts, Bots)

The Non-Human Identity Problem

Non-human identities (NHIs) now outnumber human identities 10:1 in most organizations. They are also the most neglected and most attacked.

Service Account Best Practices

1. Unique Identity

• One service account per application/integration (never share)
• Naming convention: svc-{appname}-{environment}-{purpose}
• Examples: svc-invoice-prod-api, svc-reporting-staging-etl
• Document owner, purpose, and retirement date in CMDB

2. No Passwords Where Possible

• Use managed identities (Azure MSI, AWS IAM roles, GCP service accounts)
• Use certificate-based authentication (X.509, no shared secrets)
• Use OAuth 2.0 client credentials with short-lived tokens (1-hour expiry)
• Use workload identity (IRSA, Azure AD Workload Identity, GCP Workload Identity)

3. If Password Is Required

• Generate 32+ character random password (vault-generated)
• Store in vault only (HashiCorp Vault, Azure Key Vault, AWS Secrets Manager)
• Rotate every 30–90 days (automated, no human intervention)
• Never hardcode in source code, config files, or environment variables
• Never commit to Git (use .gitignore, pre-commit hooks, secret scanning)
• Never share via email, Slack, or chat

4. Least Privilege

• Service account has ONLY the permissions needed (no "just in case" access)
• No admin rights for service accounts (ever)
• Regular access reviews (quarterly), "Does this account still need this access?"
• Time-bound access where possible (JIT for service accounts)

5. Monitoring

• Log every service account authentication
• Alert on unusual usage (wrong IP, wrong time, excessive calls)
• Alert on service account used from human workstation (major red flag)
• Alert on service account accessing data it doesn't normally access
• Alert on service account authentication outside business hours

API Authentication Patterns

Anti-Patterns, Never use API keys in:

• ❌ Frontend JavaScript (visible to users, can be extracted)
• ❌ Mobile app source code (can be decompiled)
• ❌ Public GitHub repos (scanning bots find these in minutes)
• ❌ URL parameters (logged in server logs, browser history, proxy logs)
• ❌ Email or chat (Slack, Teams, WhatsApp, searchable forever)
• ❌ Browser extensions (can be inspected)
• ❌ Client-side storage (localStorage, cookies without HttpOnly)

Database Authentication Best Practices

Secure Log-On Design

The 6 Principles of Secure Log-On

Login Page Security Checklist

Visual Design:

• No software version numbers visible ("v2.4.1", "Powered by Django 4.0")
• No "Powered by [Framework]" badges
• No links to admin panels, documentation, or API references
• Generic banner: "Authorized use only. Unauthorized access may be monitored and prosecuted."
• No organization-specific details that aid reconnaissance

Form Security:

• Password field masked by default (dots/asterisks)
• "Show password" toggle available (accessibility)
• No autocomplete for username on shared devices (optional, configurable)
• HTTPS only (HSTS enabled, TLS 1.3 minimum)
• Content Security Policy (CSP) prevents XSS on login page
• X-Frame-Options: DENY (prevents clickjacking)
• Referrer-Policy: no-referrer (prevents credential leakage in referrer)

Functional Security:

• Rate limiting implemented (per IP, per user, per session)
• Account lockout implemented (temporary, not permanent)
• CAPTCHA after failed attempts (reCAPTCHA v3 or hCaptcha)
• Log every attempt (success and failure)
• Display last login time to user (helps detect unauthorized access)
• "Forgot password" link does not confirm if username exists
• Password reset requires MFA verification (not just email)
• New device login notification sent to user
• Impossible travel detection (login from India, then 1 hour later from US)

Error Message Matrix

Rate Limiting Configuration

Progressive Delay:

Attempt 1-3:   No delay
Attempt 4-5:   5-second delay
Attempt 6-8:   30-second delay
Attempt 9-10:  5-minute lockout
Attempt 11+:   15-minute lockout + alert security team

IP-Based Throttling:

Per IP: Max 10 attempts per minute
Per IP: Max 50 attempts per hour
Per IP: Max 200 attempts per day
Exceeding → Block IP for 1 hour + alert SOC

User-Based Throttling:

Per user: Max 5 attempts per 15 minutes
Per user: Max 20 attempts per hour
Exceeding → Lock account for 30 minutes + require MFA reset

Session Management

Session Security Parameters by Risk Level

Session Token Security Best Practices

JWT Best Practices

Session Management Implementation Checklist

• Idle timeout configured (15 minutes for high-risk, 30 minutes for medium)
• Maximum session duration configured (4 hours for critical, 8 hours for high)
• Concurrent session limit enforced (1 for critical, 2 for high)
• Session regeneration after login (prevent fixation)
• Session rotation after privilege escalation
• Secure cookie attributes (HttpOnly, Secure, SameSite)
• Server-side session storage (Redis, database)
• Session invalidation on logout (not just cookie deletion)
• Session blacklist for revoked tokens
• Re-authentication for sensitive operations (password change, admin actions)
• Session anomaly detection (new device, impossible travel)
• Session audit logging (creation, termination, privilege changes)

Brute Force & Attack Protection

Attack Patterns and Defenses

Advanced Brute Force Protection

Progressive Response System:

Failed Attempts → Response
─────────────────────────────────────────────────
1-3            → Normal login (no delay)
4-5            → Add 5-second artificial delay
6-8            → Add 30-second delay + CAPTCHA
9-10           → 5-minute lockout + email notification
11-15          → 15-minute lockout + SMS alert to user
16-20          → 1-hour lockout + SOC alert + IP block
21+            → 24-hour lockout + SOC investigation + IP block + account review

Geographic-Based Protection:

Time-Based Protection:

Authentication Logging & Monitoring

What to Log (Complete Event List)

SIEM Alert Rules for Authentication

Log Retention Requirements

Zero Trust Architecture for Authentication

Zero Trust Principles Applied to Authentication

Zero Trust Authentication Stack

┌─────────────────────────────────────────────────────────────┐
│                    ACCESS REQUEST                            │
│         (User, Device, App, Location, Time)                  │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LAYER 1: IDENTITY VERIFICATION                              │
│  • Who? → User authentication (passwordless, MFA)           │
│  • What? → Device identity (certificate, TPM, compliance)   │
│  • How? → App health check (patch level, EDR status, AV)      │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LAYER 2: CONTEXTUAL EVALUATION                              │
│  • Where? → Location (geo, IP reputation, network)            │
│  • When? → Time (business hours, anomaly detection)           │
│  • Why? → Business justification (JIT, ticket reference)      │
│  • How? → Connection method (corporate VPN, public Wi-Fi)    │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LAYER 3: DYNAMIC AUTHORIZATION                              │
│  • Risk score calculated (0-100)                             │
│  • If risk > 80: Block + alert + notify manager                │
│  • If risk 50-80: Step-up MFA (additional factor)            │
│  • If risk 20-50: Grant access with standard session         │
│  • If risk < 20: Grant access with extended session          │
│  • If risk < 10: Grant access with elevated privileges (JIT) │
└─────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────┐
│  LAYER 4: CONTINUOUS VALIDATION                              │
│  • Monitor behavior during session                           │
│  • Re-evaluate if risk signals change                        │
│  • Terminate session if anomaly detected                     │
│  • Require re-authentication for sensitive operations       │
│  • Revoke access if device falls out of compliance            │
└─────────────────────────────────────────────────────────────┘

Conditional Access Policies (Example)

Zero Trust Implementation Checklist

• Identity Provider supports conditional access (Azure AD, Okta, Ping)
• Device management platform deployed (Intune, Jamf, VMware Workspace ONE)
• Device compliance policies defined (patch level, AV, EDR, encryption)
• Location policies defined (trusted IPs, blocked countries, geofencing)
• Risk scoring engine configured (Azure AD Identity Protection, Okta Risk Engine)
• Behavioral analytics deployed (UEBA, Splunk, Exabeam)
• Just-in-time access implemented for privileged roles
• Continuous access evaluation enabled (CAE in Azure AD)
• Session termination on risk signal change
• Integration with SIEM for unified visibility
• Integration with SOAR for automated response
• User training on Zero Trust principles (why it matters, how it works)

Cloud-Native Authentication (AWS, Azure, GCP)

AWS Authentication

AWS Anti-Patterns:

• ❌ Long-term IAM access keys for users (use IAM Identity Center)
• ❌ Root account used for daily operations (lock away, MFA only)
• ❌ IAM users with passwords (use IAM Identity Center instead)
• ❌ Hardcoded AWS credentials in applications or GitHub
• ❌ S3 bucket public access enabled (block all public access by default)
• ❌ IAM policies with * (Resource: *, Action: s3:*)
• ❌ IAM role trust policy with * principal

AWS Authentication Best Practices:

1. Use IAM Identity Center (SSO) for all human access
2. Use IAM Roles for all service-to-service access
3. Use IRSA for EKS pod access
4. Use IAM Database Auth for RDS
5. Enable MFA on root account (hardware key)
6. No long-term access keys for users (use SSO)
7. Rotate access keys every 90 days (if unavoidable)
8. Use AWS Secrets Manager with automatic rotation
9. Enable CloudTrail for all authentication events
10. Use AWS Config to audit IAM policies

Azure Authentication

Azure Anti-Patterns:

• ❌ Service Principal with password (use certificate or managed identity)
• ❌ Global Admin without MFA (enable MFA on all privileged roles)
• ❌ Subscription-level access for apps (use resource-level RBAC)
• ❌ Shared access signatures (SAS) with long expiry (use user delegation)
• ❌ Storage account key in application code (use Entra ID RBAC)
• ❌ SQL login with password (use Entra ID authentication)
• ❌ Local admin account on VMs (use Entra ID or LAPS)

Azure Authentication Best Practices:

1. Use Entra ID for all human authentication
2. Use Managed Identities for all service-to-service auth
3. Use Azure AD Workload Identity for AKS
4. Use Entra ID authentication for Azure SQL
5. Enable MFA on all privileged roles (Global Admin, Privileged Role Admin)
6. Use Conditional Access for risk-based policies
7. Use Privileged Identity Management (PIM) for just-in-time admin access
8. Enable continuous access evaluation (CAE)
9. Use Azure Policy to enforce authentication standards
10. Forward all Entra ID logs to Azure Monitor/Sentinel

Google Cloud Authentication

GCP Anti-Patterns:

• ❌ Service account keys downloaded to local machines (use workload identity)
• ❌ Default service account used without restrictions (create custom service accounts)
• ❌ allUsers or allAuthenticatedUsers on buckets (use IAM)
• ❌ Project-level Owner role for apps (use fine-grained IAM)
• ❌ Service account key in source code or Git (use secret manager)
• ❌ Cloud SQL with password auth (use IAM authentication)

GCP Authentication Best Practices:

1. Use Cloud Identity for all human authentication
2. Use service account impersonation for CLI access (no key files)
3. Use Workload Identity for GKE
4. Use IAM authentication for Cloud SQL
5. Enable MFA on all privileged accounts (Super Admin, Org Admin)
6. Use VPC Service Controls for perimeter security
7. Use Access Transparency for audit logging
8. Use Policy Analyzer for access reviews
9. Enable Cloud Audit Logs for all authentication events
10. Use Secret Manager for all secrets (no hardcoded credentials)

Kubernetes & Container Authentication

Kubernetes Authentication Methods

Kubernetes Authentication Best Practices

• Enable OIDC authentication (integrate with corporate IdP, Okta, Azure AD, Google)
• Disable anonymous auth (--anonymous-auth=false on API server)
• Disable basic auth (--basic-auth-file removed from API server)
• Use short-lived service account tokens (TokenRequest API, bound to pod)
• Rotate service account tokens regularly (automated)
• Use Pod Security Standards (PSS) to restrict token mounts
• Enable audit logging for all API server requests (who did what, when)
• Use RBAC with least privilege (not cluster-admin for apps)
• Enable admission controllers (PodSecurity, NodeRestriction, LimitRanger)
• Use cert-manager for automated certificate rotation
• Enable API server encryption at rest for secrets
• Use network policies to restrict API server access
• Monitor for unauthorized API server access attempts

Workload Identity

Benefit: No credentials in pods. Identity is assigned by the platform and verified cryptographically. Even if the pod is compromised, the attacker cannot extract credentials.

Implementation Example (AWS EKS + IRSA):

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app
  namespace: production
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/my-app-role
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      serviceAccountName: my-app
      containers:
      - name: my-app
        image: my-app:latest

The pod automatically receives temporary AWS credentials via the IAM role. No hardcoded credentials.

AI/ML & API Authentication

AI/ML System Authentication Patterns

AI/ML systems have unique authentication requirements because they often involve multiple components (training, serving, data, model registry) with different risk profiles.

API Authentication Best Practices

Industry-Specific Authentication Requirements

Healthcare (HIPAA / Indian Healthcare Regulations)

Financial Services (PCI DSS 4.0 / RBI / SEBI)

SaaS / B2B

Government / Defense (India / International)

Manufacturing / OT (Operational Technology)

Authentication Tool Comparison

Enterprise Identity Providers (IdP)

Password Managers (Enterprise)

Secrets Management

SIEM for Authentication Monitoring

Implementation Roadmap: 12 Weeks

Week-by-Week Detailed Plan

Week 1: Policy & Assessment

• Day 1–2: Audit all authentication mechanisms (inventory every system, every method)
• Day 3–4: Draft authentication standard (policy document)
• Day 5: Risk assessment, assign AAL to every system
• Day 6–7: Stakeholder review and approval

Week 2: MFA, Admin Critical

• Day 1: AWS root MFA (hardware key)
• Day 2: Azure Global Admin MFA (hardware key)
• Day 3: Google Super Admin MFA (hardware key)
• Day 4: Domain Admin MFA (hardware key)
• Day 5: Cloud console MFA (all admin accounts)
• Day 6: VPN MFA (all admin accounts)
• Day 7: Verification and documentation

Week 3: MFA, Workforce

• Day 1–2: Roll out TOTP/push to all employees
• Day 3–4: Enable MFA on SaaS apps (Slack, Jira, GitHub)
• Day 5–6: Enforce MFA (block non-enrolled users)
• Day 7: Report enrollment percentage

Week 4: Password Policy

• Day 1–2: Update AD/Entra ID password policy
• Day 3: Configure banned password list
• Day 4: Communicate to users (email, Slack, town hall)
• Day 5: Test policy (attempt weak passwords)
• Day 6: Monitor help desk tickets
• Day 7: Adjust based on feedback

Week 5–12: Continue per roadmap above.

Common Audit Failures & How to Fix Them

Illustrative Scenarios: When Authentication Fails

Illustrative scenario, a composite example for guidance, not a specific Singahi engagement or a verified outcome.

Illustrative Scenario 1: The SolarWinds Orion Compromise (2020), Supply Chain + Authentication Bypass

What happened: Attackers inserted a backdoor into SolarWinds Orion software updates. When 18,000+ customers installed the update, the attackers gained access to their networks. They then used compromised SAML token signing keys to forge authentication tokens, accessing cloud resources without passwords or MFA.

Authentication failures:

• SAML token signing keys were compromised (probably extracted from SolarWinds Orion itself)
• No monitoring of anomalous SAML token usage (tokens used at unusual times, from unusual locations)
• Trusted third-party software was implicitly trusted (no verification of what the software was doing)
• No certificate pinning for critical integrations (if a key changed, no one noticed)
• Over-reliance on SSO trust (once inside the SSO boundary, lateral movement was easy)

Lessons for A.8.5:

• Monitor third-party authentication tokens (SAML/OIDC) for anomalies
• Implement anomaly detection for token usage (unusual signing keys, unusual claims)
• Don't trust third-party software implicitly, verify what it does, monitor its behavior
• Use certificate pinning for critical integrations (alert if a key changes unexpectedly)
• Implement continuous validation (don't trust the SSO token forever)
• Separate admin accounts from SSO where possible (break-glass not dependent on SSO)

How to prevent this:

1. Monitor SAML/OIDC token signing key usage (who signed what, when)
2. Alert on new signing certificates without change control approval
3. Implement token binding (bind token to specific IP/device)
4. Use short-lived tokens (1 hour maximum, not 8+ hours)
5. Monitor for unusual token claims (admin privileges in unexpected tokens)
6. Separate cloud admin accounts from SSO (local accounts with MFA, not federated)

Illustrative Scenario 2: The Twitter Bitcoin Scam (2020), Social Engineering + Weak Internal Auth

What happened: Attackers gained access to Twitter's internal admin tools through social engineering of employees (spear phishing). They then tweeted Bitcoin scam messages from high-profile accounts (Obama, Biden, Musk, Gates, Apple). The attack was visible to the entire world.

Authentication failures:

• Internal admin tools had weak or no MFA ("internal only" is not a security boundary)
• Social engineering bypassed authentication (employees were tricked into giving access)
• Shared admin tools without proper access controls (one compromised account = full access)
• No just-in-time access (admin tools had standing access, not time-bound)
• No session monitoring (unusual usage patterns went undetected)

Lessons for A.8.5:

• All internal tools must have MFA, even "internal only" (perimeter is dead)
• Train employees on social engineering (A.6.3, awareness is part of authentication)
• Implement just-in-time (JIT) admin access (only when needed, automatically revoked)
• Admin tools should require step-up authentication (even if already logged in)
• Implement session monitoring for admin tools (alert on unusual actions)
• Separate admin functions from general access (different tools, different auth)

How to prevent this:

1. MFA on every internal tool, no exceptions
2. JIT admin access (request → approve → time-bound access → auto-revoke)
3. Admin session recording (record what they did, not just that they logged in)
4. Social engineering simulation (test employees quarterly, train failures)
5. Admin access alerts (alert on unusual admin actions, even if authenticated)
6. Principle of least privilege for admin accounts (no one admin can do everything)

Illustrative Scenario 3: The Uber Breach (2022), MFA Fatigue Attack

What happened: A teenager bought stolen credentials for an Uber contractor from a dark web marketplace. Because the contractor had MFA enabled (push notifications), the attacker used MFA fatigue (bombarding the user with push notifications until they accepted one) to gain access. From there, the attacker accessed Uber's internal systems, including AWS, G Suite, Slack, and internal code repositories.

Authentication failures:

• Push notification fatigue attack succeeded (user accepted after 10+ notifications)
• No "number matching" or verification on MFA prompts (just "accept/deny")
• Contractor had excessive access (not least privilege, could access everything)
• No risk-based step-up (unusual location should have triggered additional verification)
• No push notification limits (unlimited push notifications allowed)
• No contextual information in push (user didn't see WHERE the login was from)

Lessons for A.8.5:

• Use "number matching" MFA (user must enter number from login screen into app)
• Limit push notifications (max 3 attempts, then lockout)
• Implement risk-based step-up (unusual location = additional verification)
• Apply least privilege to contractors and vendors (scope access tightly)
• Show contextual information in push notifications (location, IP, device)
• Train users on MFA fatigue attacks (never accept unexpected push notifications)
• Consider hardware keys for high-risk accounts (no push to fatigue)

How to prevent this:

1. Deploy number matching on all push notifications (Microsoft, Duo, Okta support this)
2. Limit push notifications to 3 per login attempt
3. Implement push notification cool-down (5-minute delay after 2 declines)
4. Show location and device in push notification ("Login from Mumbai, India?")
5. Use hardware keys for admin accounts (no push notifications to fatigue)
6. Train all users on MFA fatigue (quarterly awareness training)
7. Implement risk-based policies (new location = additional verification)

Illustrative Scenario 4: The MGM Resorts Ransomware (2023), Social Engineering + MFA Bypass

Authentication failures:

• Help desk could bypass MFA with a phone call (no verification process)
• No out-of-band verification for MFA reset (just one phone call)
• No verification of identity before MFA reset (no manager approval, no in-person)
• No monitoring of MFA reset events (help desk actions went unlogged)
• No separation of duties for MFA reset (help desk could do everything)
• No time-bound access (once in, they stayed for days)

Lessons for A.8.5:

• MFA reset requires out-of-band verification (manager approval, in-person, video call)
• Help desk cannot bypass MFA without documented exception (and it should be rare)
• Identity verification for MFA reset must be stronger than the original auth (can't be easier to reset than to authenticate)
• Implement "MFA reset" as a formal change request with approval workflow
• Log all MFA reset events (who reset, when, why, approved by whom)
• Implement time-bound access (even after MFA reset, access expires)
• Require video verification for MFA reset (show ID, confirm identity)

How to prevent this:

1. MFA reset requires manager approval (out-of-band, not via the same help desk call)
2. MFA reset requires video verification (employee shows ID, confirms identity)
3. MFA reset triggers alert to user ("Your MFA was reset. If you didn't request this, call security.")
4. Log all MFA reset events in SIEM (alert on unusual reset patterns)
5. Implement separation of duties (help desk can reset MFA, but only security can approve access)
6. Time-bound access after MFA reset (24-hour expiry, must re-verify)
7. Require in-person verification for MFA reset (if possible) or video call with ID

Illustrative Scenario 5: Indian Fintech Data Breach (2024), API Key Exposure

What happened: A major Indian fintech company had an API key hardcoded in their mobile application. A security researcher extracted the key, gaining access to customer transaction data, PII, and financial records affecting 2 million users. The API key had full read/write access to the production database.

Authentication failures:

• API key hardcoded in mobile app source code (easily extracted via decompilation)
• API key had full database access (no principle of least privilege)
• API key was not rotated (same key for 2+ years)
• No API key monitoring (no one noticed unusual usage)
• No API rate limiting (researcher could download entire database)
• No API key scoping (one key for everything, not per-endpoint)

Lessons for A.8.5:

• Never hardcode API keys in client applications (mobile, frontend, desktop)
• Use backend-for-frontend (BFF) pattern (client talks to your backend, backend talks to API)
• API keys must be scoped (read-only, write-only, per-endpoint)
• API keys must be rotated regularly (90 days maximum)
• API keys must be monitored (alert on unusual usage)
• API keys must be rate-limited (prevent bulk data extraction)
• Use OAuth 2.0 + PKCE for mobile apps (no static API keys)

How to prevent this:

1. No API keys in client applications (use BFF pattern or OAuth 2.0 + PKCE)
2. Scope API keys to specific endpoints (not * access)
3. Rotate API keys every 90 days (automated)
4. Monitor API key usage (alert on unusual patterns)
5. Rate limit API calls (per key, per user, per IP)
6. Use OAuth 2.0 for mobile apps (short-lived tokens, no static keys)
7. Implement API gateway (centralized auth, rate limiting, logging)
8. Regular code scanning for API keys (GitHub secret scanning, truffleHog)

Metrics & KPIs

Authentication Security Scorecard

Sample Dashboard Layout

┌──────────────────────────────────────────────────────────────┐
│  AUTHENTICATION SECURITY DASHBOARD — June 2026                │
├──────────────────────────────────────────────────────────────┤
│                                                              │
│  MFA Enrollment        97% ████████████████████████████░     │
│  Passwordless          34% ████████████░░░░░░░░░░░░░░░     │
│  Service Accounts (MI)  62% ████████████████░░░░░░░░░░      │
│  Failed Login Rate      0.3% █░░░░░░░░░░░░░░░░░░░░░░░░      │
│  SSO Coverage          85% █████████████████████░░░░░      │
│                                                              │
├──────────────────────────────────────────────────────────────┤
│  ACTIVE ALERTS (Last 24h)                                    │
│  🔴 2 Account takeover attempts (blocked)                     │
│  🟡 12 Impossible travel alerts (investigated)                │
│  🟡 3 Dormant account activations (verified)                  │
│  🟢 0 Brute force campaigns (blocked)                          │
│  🟢 0 Credential stuffing attempts (blocked)                   │
│                                                              │
├──────────────────────────────────────────────────────────────┤
│  TOP RISKS                                                   │
│  1. 15 admin accounts still on SMS MFA → migrate to TOTP     │
│  2. 8 legacy apps without MFA → conditional access planned  │
│  3. 23 service accounts with passwords in code → vault migration│
│  4. 3 certificates expire in <30 days → renewal in progress  │
│  5. 2 apps using basic auth → migration to OIDC planned      │
├──────────────────────────────────────────────────────────────┤
│  AUDIT READINESS                                             │
│  Policy: ✅ Current (v2.1, approved 2026-01-15)               │
│  MFA: ✅ 100% admin, 97% workforce                          │
│  Logging: ✅ 100% coverage, 1-year retention                 │
│  Exceptions: 4 documented, all with risk acceptance          │
│  Last audit: 0 major findings (2026-03-15)                    │
└──────────────────────────────────────────────────────────────┘

Multi-Framework Mapping

Control Mapping Matrix

SOC 2 Mapping Detail

• CC6.1, Logical access controls (authentication, authorization, access provisioning)
• CC6.2, Access removal (provisioning, deprovisioning, access reviews)
• CC7.1, System operations (monitoring, change management)
• CC7.2, System monitoring (security event detection, incident response)

PCI DSS 4.0 Mapping Detail

• 8.2.3, Strong authentication for remote access to CDE
• 8.3.4, Multi-factor authentication for remote access to CDE
• 8.4.2, Unique IDs for system components
• 8.3.5, Password complexity requirements
• 8.3.6, Password rotation (90 days for CDE)
• 8.1.8, Inactivity timeout (15 minutes)
• 8.3.2, Strong cryptography for authentication

NIST 800-53 Rev 5 Mapping Detail

• IA-2, Identification and authentication (organizational users)
• IA-5, Authenticator management (passwords, tokens, certificates)
• AC-7, Unsuccessful logon attempts (lockout, monitoring)
• AC-17, Remote access (secure remote authentication)
• IA-4, Identifier management (unique user IDs)
• AC-6, Least privilege (access restriction)
• AU-6, Audit review (log analysis)
• AU-12, Audit generation (logging)
• SI-4, Information system monitoring (anomaly detection)

DORA (Digital Operational Resilience Act) Mapping Detail

• Art. 12, ICT risk management (authentication as part of risk management)
• Art. 9, Governance (access control policies)
• Art. 10, ICT risk management framework
• Art. 13, Incident management (authentication as part of detection)
• Art. 15, Digital operational resilience testing

CIS Controls v8 Mapping Detail

• CIS 6.1, Establish an access granting process
• CIS 6.2, Establish an access revoking process
• CIS 6.3, Require MFA for externally-exposed applications
• CIS 6.4, Require MFA for remote network access
• CIS 6.5, Require MFA for administrative access
• CIS 6.6, Establish and maintain an inventory of authentication and authorization systems
• CIS 6.7, Centralize access control
• CIS 6.8, Define and maintain role-based access control
• CIS 8.5, Collect detailed audit logs
• CIS 8.6, Collect DNS query audit logs
• CIS 8.7, Collect URL request audit logs
• CIS 8.8, Collect command-line audit logs

Indian Regulatory Context

Digital Personal Data Protection Act (DPDP Act) 2023

Information Technology Act 2000 (as amended)

RBI (Reserve Bank of India) Guidelines

SEBI (Securities and Exchange Board of India) Guidelines

IRDAI (Insurance Regulatory and Development Authority of India) Guidelines

CERT-In Guidelines

Maturity Model: Level 1 to Level 5

Authentication Security Maturity Assessment

Level 1: Ad Hoc

Indicators:

• No documented authentication policy
• No MFA (or only on 1-2 systems)
• Weak passwords (8 characters, complexity rules)
• No session timeouts
• No authentication logging
• Shared accounts common
• Default passwords on network equipment
• No access reviews

Actions to reach Level 2:

1. Draft authentication policy (1 week)
2. Enable MFA on admin accounts (1 week)
3. Implement password policy (12+ characters) (1 week)
4. Configure basic session timeouts (1 week)
5. Enable authentication logging (2 weeks)

Level 2: Developing

Indicators:

• Basic authentication policy exists but not enforced
• MFA for some admin accounts only
• Passwords still weak but improving
• Basic session timeouts on some systems
• Logging exists but not centralized
• Some access reviews but not regular

Actions to reach Level 3:

1. Enforce MFA on all admin accounts (2 weeks)
2. Update password policy to modern standards (12+ chars, no rotation) (1 week)
3. Implement SSO for top 10 apps (4 weeks)
4. Centralize authentication logs (4 weeks)
5. Implement quarterly access reviews (2 weeks)

Level 3: Defined

Indicators:

• Documented, enforced authentication policy
• MFA for all admin accounts, some workforce
• Modern password policy (12+ chars, no rotation, breach detection)
• Standard session timeouts across all apps
• Centralized logging with basic monitoring
• Regular access reviews
• Service accounts partially managed

Actions to reach Level 4:

1. Enforce MFA for all users (4 weeks)
2. Implement risk-based authentication (AAL levels) (4 weeks)
3. Deploy SIEM with UEBA (8 weeks)
4. Implement conditional access (4 weeks)
5. Migrate service accounts to managed identities (8 weeks)

Level 4: Managed

Indicators:

• MFA for all users (95%+)
• Risk-based authentication implemented
• SSO for 90%+ of applications
• Advanced session management (risk-based timeouts)
• SIEM with UEBA and anomaly detection
• Automated access reviews
• Service accounts fully managed
• Conditional access policies active

Actions to reach Level 5:

1. Pilot passwordless authentication (8 weeks)
2. Implement Zero Trust architecture (12 weeks)
3. Deploy continuous access evaluation (8 weeks)
4. Implement AI-driven threat detection (12 weeks)
5. Achieve 100% passwordless for standard users (12 weeks)

Level 5: Optimized

Indicators:

• Passwordless for 80%+ of users
• Zero Trust architecture fully implemented
• Continuous validation (re-auth on risk signals)
• AI-driven anomaly detection and response
• Predictive risk scoring
• Automated incident response
• Full visibility into all authentication events
• No standing privileges (everything JIT)

Benchmarking:

• Compare with industry peers (Gartner, Forrester benchmarks)
• Continuous improvement via threat intelligence
• Regular red team exercises focused on authentication bypass
• Participate in industry information sharing (ISACs)
• Publish anonymized metrics (contribute to industry benchmarks)

RACI Matrix

Authentication Management RACI

Legend: A = Accountable (approves), R = Responsible (does the work), C = Consulted (provides input), I = Informed (kept updated)

Detailed Role Definitions

Documentation and Evidence Requirements

Required Documents for A.8.5

Evidence for Audits

Continuous Improvement

Authentication Improvement Cycle

┌─────────────────────────────────────────────────────────────────┐
│                    PLAN                                          │
│  • Threat intelligence review                                   │
│  • Industry benchmark comparison                                  │
│  • Audit findings remediation                                    │
│  • New technology evaluation                                     │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    DO                                            │
│  • Implement improvements                                        │
│  • Update policies and procedures                                │
│  • Deploy new technologies                                       │
│  • Train users on changes                                        │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    CHECK                                         │
│  • Metrics review (KPI dashboard)                                │
│  • Penetration testing                                           │
│  • Red team exercises                                            │
│  • Audit and assessment                                          │
│  • User feedback                                                 │
└─────────────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────────────┐
│                    ACT                                           │
│  • Adjust based on findings                                      │
│  • Update risk assessment                                        │
│  • Communicate changes                                           │
│  • Document lessons learned                                      │
└─────────────────────────────────────────────────────────────────┘

Improvement Triggers

Annual Improvement Agenda

FAQ

Is MFA mandatory for ISO 27001?

Strictly, the standard does not explicitly mandate MFA for every user. However, for any system processing sensitive data, MFA is the de facto expectation. Auditors will question single-factor authentication for anything beyond low-sensitivity systems. Our recommendation: treat MFA as mandatory for all users, document exceptions with risk acceptance.

What password length does ISO 27001 require?

The standard does not specify a length. Modern best practice (NIST SP 800-63B, NCSC) recommends minimum 12 characters for standard users, 15 for privileged users. Focus on length over complexity. A 12-character passphrase is stronger than an 8-character complex password.

Should we force password rotation?

No. NIST SP 800-63B and modern research show that forced rotation weakens passwords (users increment: Password1, Password2). Rotate only on compromise, suspicion, or employee departure. Service accounts should rotate every 30–90 days (automated).

Are biometrics sufficient as a single factor?

No. Biometrics can fail (injury, sensor issues, privacy concerns). Always supplement with a fallback method (hardware key or password). Also, biometric data is PII, handle it under GDPR/DPDP Act privacy rules. Use biometrics as one factor in MFA, not as the only factor.

What about shared accounts?

Eliminate them. Shared accounts ("admin", "support", "root") destroy accountability. If a shared account is technically required:

• Store password in vault (no individual knows it)
• Implement checkout/check-in procedure (who used it, when, why)
• Record session (everything they did)
• Rotate password immediately after each use
• Require approval for each checkout

How do we handle legacy systems that don't support MFA?

Document the exception with:

• Risk acceptance form (CISO approved)
• Compensating controls (network segmentation, IP whitelisting, no internet access)
• Replacement plan with timeline
• Quarterly review
• Retirement target date

Never leave a legacy system unprotected without documented justification.

What's the difference between A.8.5 and A.5.17?

• A.8.5 = Secure Authentication (the technical procedures and technologies: MFA, password policy, session management)
• A.5.17 = Authentication Information (how credentials are created, distributed, managed, and revoked: password resets, credential issuance, revocation)

They are siblings. A.8.5 is the "what" (MFA, password policy). A.5.17 is the "how" (issuing credentials, resetting passwords, revoking access). Both must be implemented together.

Can we use SMS for MFA?

Only as a transitional measure. SMS is vulnerable to SIM swapping, SS7 attacks, interception, and phishing. Target: migrate all users from SMS to TOTP or hardware keys within 6 months. If you must use SMS today, require it only for low-risk systems and have a migration plan.

What is the fastest path to A.8.5 compliance?

1. Week 1: Enable MFA on all admin accounts (hardware key)
2. Week 2: Update password policy (12+ chars, no rotation, breach detection)
3. Week 3: Enable MFA on all SaaS apps (TOTP/push)
4. Week 4: Document authentication standard (policy document)
5. Week 5: Configure session timeouts (30 min idle, 8 hours max)
6. Week 6: Centralize authentication logs (SIEM)

This gets you to 80% compliance in 6 weeks. The remaining 20% (service accounts, conditional access, passwordless, risk-based) takes 6–12 weeks.

How much does full A.8.5 implementation overhead?

What's the difference between authentication and authorization?

Authentication = Proving who you are ("I am Priya Sharma") Authorization = Determining what you can do ("Priya can access the AWS console but not the financial database")

A.8.5 covers authentication. A.5.15 covers authorization. Both are required, authentication proves identity, authorization controls access.

How do we handle contractor authentication?

Contractors need the same authentication rigor as employees, with additional controls:

• Time-limited accounts (auto-expire after contract end date)
• Location-restricted access (corporate office only, or VPN from known IP)
• Scoped access (only the systems they need, not everything)
• Separate IdP group (distinguish contractors from employees)
• Enhanced monitoring (log everything they do)
• Immediate deprovisioning on contract end

What about customer authentication (B2C)?

Customer authentication has different requirements:

• Friction vs. security balance: Customers abandon if authentication is too complex
• Passkeys recommended: Best UX, no password reset, phishing-resistant
• Progressive authentication: Low friction for browsing, stronger auth for transactions
• MFA for high-value actions: Payments, password changes, address changes
• Social login acceptable: Google, Apple, Facebook login (with your own verification)
• Session management: Longer sessions for convenience, but re-auth for sensitive actions

How do we handle authentication across multiple cloud providers?

Multi-cloud authentication requires federation:

1. Primary IdP: One corporate IdP (Okta, Azure AD, Ping)
2. Federation: SAML/OIDC to AWS IAM Identity Center, GCP Cloud Identity, Azure AD
3. Centralized policy: MFA, password policy, session management enforced at IdP
4. Consistent logging: All auth events forwarded to central SIEM
5. Single dashboard: Unified view of authentication across all clouds

What is continuous authentication?

Continuous authentication evaluates risk throughout the session, not just at login:

• Behavioral biometrics: Typing pattern, mouse movement (is it still the same user?)
• Device posture: Is the device still compliant? (AV, EDR, patch level)
• Location stability: Is the user still in the same location?
• Session anomalies: Is the user doing things they don't normally do?
• Re-authentication: Step-up auth if risk signals change

Technology: Microsoft Continuous Access Evaluation (CAE), Okta Risk Engine, behavioral analytics (Exabeam, Splunk UBA).

How do we handle BYOD authentication?

Bring Your Own Device requires special authentication considerations:

• Device registration: Register BYOD in MDM (Microsoft Intune, VMware Workspace ONE)
• Device compliance: Check patch level, AV, encryption before granting access
• Conditional access: Different policy for BYOD vs corporate devices
• App protection: Mobile app management (MAM) to protect corporate data
• No offline access: Require internet connectivity for authentication (no cached credentials)
• Wipe capability: Ability to wipe corporate data from BYOD without touching personal data

What about biometric authentication privacy?

Biometric data is sensitive PII. Handle it carefully:

• Never store raw biometric data: Store templates, not images
• Encryption: Encrypt biometric templates at rest and in transit
• Consent: Obtain explicit consent for biometric collection
• DPDP Act compliance: Biometric data is sensitive personal data under DPDP Act
• Breach notification: Biometric data breach = mandatory notification
• Alternative: Always offer non-biometric fallback (hardware key, password)
• Storage: Store biometric data separate from other PII
• Retention: Delete biometric data when employment ends (unless legally required)

References

Standards and Frameworks

Indian Regulations

Technical References

Books and Resources

Industry Reports

📧 Questions? Email us at security@singahi.com

End of ISO 27001:2022 Annex A 8.5, Secure Authentication: The Definitive Implementation Guide