Authentication Strategy Design

Where Authentication Decisions Go Wrong

A mid-size healthcare company deploys MFA for its patient portal: username, password, and a one-time code sent via SMS. The security team is satisfied — three steps, must be secure. Then a threat actor intercepts the SMS through a SIM swap, logs in with stolen credentials, and exfiltrates 50,000 patient records. The authentication had multiple steps but was designed around convenience rather than threat modeling.

Authentication strategy is not about adding more steps. It is about selecting the right factors, the right mechanisms, and the right adaptive policies for the risk profile of what you are protecting.

This module covers CISSP objective 5.2: design and validate authentication strategies. The exam expects you to think like an architect selecting authentication mechanisms based on risk, not a technician configuring login prompts.

Authentication Factors

Authentication proves that a subject is who they claim to be. The strength of that proof depends on the factors used.

The Three Traditional Factors

• Something you know — Passwords, PINs, passphrases, security questions. The weakest factor because knowledge can be shared, guessed, or stolen without the owner’s awareness.
• Something you have — Smart cards, hardware tokens, mobile devices, cryptographic keys. Stronger than knowledge factors because possession is harder to replicate remotely. Loss or theft is the primary risk.
• Something you are — Fingerprints, iris patterns, facial geometry, voice patterns. Biometrics are difficult to forge but impossible to change if compromised. A stolen password can be reset. A stolen fingerprint template cannot.

Context-Based Factors

Modern authentication systems add contextual signals that do not replace the three traditional factors but modify the authentication requirements based on risk:

• Somewhere you are — Geolocation, IP address, network segment. A login from the corporate network may require fewer factors than one from an unknown IP in a different country.
• Something you do — Behavioral biometrics such as typing cadence, mouse movement patterns, or gait analysis. These create a behavioral profile that is difficult for an attacker to replicate.
• When you authenticate — Time-based restrictions. An admin login at 3 AM from a personal device triggers additional verification that the same login at 9 AM from a corporate workstation does not.

Multi-Factor Authentication Design

MFA requires factors from at least two different categories. The design challenge is selecting the right combination for the risk level.

• Standard business applications — Password + mobile push notification (something you know + something you have). Balances security with usability for everyday access.
• Privileged administration — Hardware token + biometric + PIN (something you have + something you are + something you know). High-assurance authentication for accounts that can modify critical infrastructure.
• Customer-facing applications — Risk-based approach where additional factors are triggered only when the risk score exceeds a threshold. Low-risk transactions may require only a password; high-risk transactions add a second factor.

MFA is not binary. The strength of MFA depends on the quality of each factor. SMS-based OTP is weaker than a FIDO2 hardware key, even though both qualify as “something you have.” The exam distinguishes between checking the MFA box and designing effective MFA.

Single Sign-On

SSO allows a user to authenticate once and access multiple systems without re-entering credentials. This improves usability and reduces password fatigue, but it concentrates authentication risk — if the SSO credential is compromised, every connected system is exposed.

Kerberos

Kerberos is a ticket-based authentication protocol used primarily in on-premises Active Directory environments.

1. The user authenticates to the Authentication Server (AS) and receives a Ticket Granting Ticket (TGT)
2. When accessing a service, the user presents the TGT to the Ticket Granting Service (TGS) to receive a service ticket
3. The service ticket is presented to the target service, which validates it without requiring the user to re-authenticate

Key exam points: Kerberos uses symmetric cryptography, depends on time synchronization (tickets have timestamps to prevent replay), and requires a trusted third party (the Key Distribution Center). If the KDC is compromised, the entire authentication infrastructure is compromised.

SAML

Security Assertion Markup Language (SAML) is an XML-based standard for exchanging authentication and authorization data between parties, primarily used for web-based SSO.

• The Identity Provider (IdP) authenticates the user and creates a SAML assertion
• The Service Provider (SP) trusts the IdP and grants access based on the assertion
• SAML assertions contain authentication statements (how the user authenticated), attribute statements (user attributes like role or department), and authorization decision statements

OAuth 2.0 and OpenID Connect

OAuth 2.0 is an authorization framework — it grants access to resources without sharing credentials. OpenID Connect (OIDC) adds an authentication layer on top of OAuth.

• OAuth 2.0 — Issues access tokens that grant specific permissions to resources. The user authorizes a client application to act on their behalf. OAuth does not tell the application who the user is — only what they can access.
• OpenID Connect — Extends OAuth by adding an ID token that identifies the authenticated user. OIDC answers “who is this person?” while OAuth answers “what can this application do?”

The exam tests whether you understand the distinction: OAuth is for authorization, OIDC is for authentication. If a question asks about verifying user identity, the answer is OIDC or SAML. If it asks about granting application-level resource access, the answer is OAuth.

Session Management

Authentication is a point-in-time event. Session management determines how long that authentication remains valid and under what conditions it should be re-evaluated.

• Session timeouts — Idle timeout ends sessions after inactivity. Absolute timeout ends sessions after a fixed duration regardless of activity. Both limit the window of opportunity for session hijacking.
• Session tokens — Random, unpredictable tokens that identify the session. Tokens should be transmitted over encrypted channels, stored securely, and invalidated on logout.
• Re-authentication triggers — Certain actions (changing a password, initiating a financial transfer, accessing a higher-classification resource) should require the user to re-authenticate, even within an active session.
• Concurrent session limits — Restricting the number of active sessions per user prevents credential sharing and limits the impact of stolen session tokens.

Credential Management and Password Policy

Credential management covers the full lifecycle: creation, storage, distribution, use, and revocation.

• Password storage — Passwords must be hashed with a salt using a modern algorithm (bcrypt, scrypt, Argon2). Storing passwords in plaintext or with weak hashing (MD5, SHA-1) is a fundamental security failure.
• Password policies — Minimum length (NIST recommends at least 8 characters, many organizations require 12+), no composition rules that encourage predictable patterns, screening against breached password lists, and no forced periodic rotation unless compromise is suspected.
• Credential vaulting — Privileged credentials (service accounts, root passwords, API keys) should be stored in a credential vault that controls access, rotates passwords automatically, and logs every retrieval.

Passwordless Authentication

Passwordless authentication removes the knowledge factor entirely, relying instead on possession and biometric factors. FIDO2/WebAuthn is the leading standard.

• The user registers a device (laptop, phone, security key) with the service
• Authentication uses a cryptographic challenge-response: the device signs a challenge with a private key, and the service verifies with the registered public key
• The private key never leaves the device and is often protected by a biometric or local PIN

Passwordless eliminates credential stuffing, phishing of passwords, and password reuse — the three most common authentication attacks. The trade-off is device dependency and recovery complexity.

Biometric Authentication Design

Beyond the accuracy metrics covered in Module 32, authentication architects must consider biometric-specific risks:

• Spoofing — Presentation attacks using fake fingerprints (gummy bears, 3D prints), photos, or voice recordings. Liveness detection mitigates this by verifying the biometric sample comes from a living person.
• Template protection — Biometric templates stored centrally become high-value targets. If a fingerprint template database is breached, those credentials cannot be revoked. On-device storage and template encryption reduce this risk.
• Enrollment quality — Poor enrollment creates templates that either reject legitimate users frequently or accept impostors. Enrollment should require multiple samples under controlled conditions.
• Cultural and accessibility considerations — Some biometric modalities create friction for specific populations. Facial recognition accuracy varies across demographics. Fingerprint readers do not work well for manual laborers with worn fingerprints. A well-designed system offers alternative authentication paths.

Just-in-Time Access and Adaptive Authentication

Just-in-Time (JIT) Access

JIT access grants elevated privileges only when needed and automatically revokes them after a defined period. Instead of granting permanent administrator access, a user requests elevated access for a specific task, receives it for a limited window, and returns to standard privileges when the window expires.

JIT reduces the standing privilege footprint — the number of accounts with persistent elevated access. Fewer standing privileges means fewer targets for attackers and less damage from credential compromise.

Adaptive / Risk-Based Authentication

Adaptive authentication adjusts the authentication requirements based on a real-time risk assessment. The system evaluates contextual signals and assigns a risk score:

• Low risk (known device, corporate network, normal hours) — Standard authentication, possibly reduced factors
• Medium risk (new device, different city, unusual time) — Step-up authentication with an additional factor
• High risk (impossible travel, known malicious IP, simultaneous sessions from different countries) — Block access and alert security team

Adaptive authentication balances security and usability by applying friction proportional to risk. Low-risk access is seamless; high-risk access faces stronger barriers. This approach recognizes that a one-size-fits-all authentication policy either under-protects high-risk scenarios or over-burdens low-risk ones.

Pattern Recognition

Authentication strategy questions follow these structures:

• Factor selection — A scenario describes a risk profile. You select the authentication approach that matches the risk level. Higher-risk assets demand stronger, more diverse factors.
• SSO risk trade-off — SSO questions often present the convenience benefit, then ask about the concentrated risk. The answer involves protecting the SSO credential with strong MFA.
• Protocol selection — A question describes a use case (web SSO, API authorization, on-premises authentication). Match the protocol: SAML for web SSO, OAuth for API authorization, Kerberos for on-premises, OIDC for identity verification.
• Adaptive trigger — A scenario describes anomalous behavior. The answer is step-up authentication or access denial based on the risk signal.

Trap Patterns

Watch for these wrong answers:

• “OAuth authenticates users” — OAuth is an authorization framework. It delegates access to resources. OpenID Connect adds the authentication layer. The exam tests this distinction directly.
• “SMS OTP is strong MFA” — SMS is vulnerable to SIM swapping, interception, and social engineering against carriers. It qualifies as a second factor but is weaker than app-based TOTP or hardware tokens. The exam prefers answers that acknowledge this weakness.
• “Biometrics cannot be compromised” — Biometric templates can be stolen, and biometric samples can be spoofed. The key difference is that compromised biometrics cannot be reissued like a password or token.
• “SSO eliminates credential risk” — SSO reduces the number of credentials but concentrates risk on a single authentication event. A compromised SSO credential grants access to every connected system.
• “Forced password rotation improves security” — NIST 800-63B guidance discourages mandatory periodic rotation because it encourages weak, predictable password patterns. Rotation should be triggered by evidence of compromise, not a calendar.

Scenario Practice

Question 1

A cloud-native company is designing authentication for its internal engineering platform. Engineers access production systems to deploy code and manage infrastructure. The platform currently uses passwords only. The security team wants to implement MFA but the engineering team pushes back on any solution that slows down their workflow.

What is the BEST authentication strategy?

A. Implement SMS-based OTP as the second factor since it is the most widely supported
B. Deploy FIDO2 hardware security keys that authenticate with a touch, providing strong MFA with minimal workflow disruption
C. Add security questions as a second step to verify engineer identity
D. Keep passwords but increase minimum length to 20 characters

Question 2

An organization deploys SSO across all business applications using SAML. Six months later, a phishing attack compromises an employee’s SSO credentials. The attacker accesses the employee’s email, HR system, financial application, and cloud storage before being detected.

What control would have MOST effectively limited the blast radius?

A. Requiring MFA for the SSO authentication, making the compromised password insufficient for access
B. Disabling SSO and requiring separate credentials for each application
C. Implementing shorter session timeouts across all connected applications
D. Training employees to recognize phishing emails

Question 3

A bank’s risk-based authentication system flags a login attempt: the user is accessing from a new device in a country they have never logged in from before, at 2 AM local time. The user’s account has administrative privileges over customer account management.

What should the adaptive authentication system do?

A. Allow access but log the event for later review
B. Allow access after the user answers their security question
C. Block the access attempt and alert the security team for investigation
D. Allow access but restrict the user to read-only mode

Key Takeaway