Authentication Security: Architect's Strategic Defense

In the previous parts of this series, we discussed the authentication vulnerability from the developer’s point of view. We discussed password requirements based on NIST guidelines, rate limiting using exponential backoff, preventing username enumeration, secure transmission of credentials, password reset token management, multi-stage authentication bypass, secure password storage using bcrypt and Argon2id algorithms, session management, and defense-in-depth using CAPTCHA and risk-based authentication.

In this fourth part of the series, we are moving from the developer’s perspective to the strategy side. While it is important for security architects to have the knowledge of how to fix authentication vulnerabilities, it is equally important to understand how to build systems and processes that prevent these vulnerabilities from occurring in the first place.

Authentication vulnerabilities are categorized under CWE-287 and are included in A07:2025 Identification and Authentication Failures under the OWASP Top 10 2025. While authentication vulnerabilities have been known for decades, the issue remains an organizational problem. Technical controls are necessary but not sufficient without governance, measurement, and continuous improvement.

1. Threat Modeling for Authentication

Security architects must be aware of the attack scenarios before they start to design security controls. In authentication, threat modeling helps identify where vulnerabilities might exist, how they might be exploited, and what business impact might result.

Attack Scenarios and Business Impact

Credential Stuffing

In this type of attack, attackers use stolen login credentials from previous breaches to attempt login into our system. Users often share passwords across different systems. This allows attackers to gain access to our system using stolen login credentials from Company A, where they were previously breached. The business impact includes account takeover, fraud, and regulatory risks. This type of attack can result in millions of credentials being tested by attackers.

Brute Force Attacks

In this type of attack, attackers test various password combinations against known account credentials. A single server could test thousands of passwords per minute if there are no rate limits. The business impact includes account takeover of users who have weak passwords.

Phishing and Social Engineering

In this type of attack, attackers trick users into revealing their login credentials. The technical controls that could help prevent this type of attack are limited. The best solution to this type of attack includes user education and phishing-resistant authentication, such as FIDO2 and WebAuthn. The business impact includes account takeover and potentially lateral movement if the compromised account has elevated privileges.

Session Hijacking

In this type of attack, attackers steal users' session tokens using XSS, network interception, or malware. Once attackers have acquired a valid session token, they are granted access without having to provide any login credentials. The business impact includes unauthorized access using the victim's account and all their privileges. The attack also goes undetected because the attacker uses legitimate user credentials.

Password Reset Exploitation

In this type of attack, attackers exploit weak password reset flows to gain access to user accounts. The attackers often exploit weak password reset flows by using social engineering tactics against support staff. The business impact includes account takeover without the need to know the original password. This type of attack often goes undetected until the legitimate user attempts to login.

MFA Bypass

In this type of attack, attackers exploit weaknesses in the implementation of multi-factor authentication, social engineering, or MFA fatigue. The business impact includes undermining the strongest authentication control.

STRIDE Mapping

Applying the STRIDE threat model to authentication:

STRIDE Category	Authentication Manifestation
Spoofing	Credential theft, session hijacking, phishing
Tampering	Token manipulation, session fixation, cookie tampering
Repudiation	Shared accounts, insufficient logging, audit trail gaps
Information Disclosure	Username enumeration, timing attacks, error message leakage
Denial of Service	Account lockout abuse, resource exhaustion, authentication system overload
Elevation of Privilege	Privilege escalation via compromised admin accounts, role manipulation

This multi-category mapping explains why authentication consistently ranks high in vulnerability taxonomies. Weaknesses enable multiple attack types, each with potentially severe consequences.

Attack Tree Analysis

A simplified attack tree for authentication exploitation:

Each node represents an opportunity for controls. Defense in depth means placing obstacles at multiple points, so failure at one level does not mean complete compromise.

2. Risk-Based Prioritization

Not all vulnerabilities have the same level of associated risk. The remediation priority should be determined by the exploitability and impact.

CVSS Contextualization

The base score for authentication vulnerabilities varies between 5.0 and 9.8. However, there are other factors that influence the risks associated with authentication vulnerabilities.

Factors that increase the associated risks:

Internet exposure
Critical user accounts
Absence of MFA
Data exposure after authentication
Compliance and regulatory requirements

Factors that decrease the associated risks:

Internal-only applications
MFA is enforced for all users
Monitoring and alerting capabilities
Limited data exposure after authentication
Defense-in-depth capabilities

Risk Scoring Framework

A practical risk scoring approach for authentication findings:

Factor	Low (1)	Medium (2)	High (3)
Exploitability	Complex attack chain required	Standard tools/techniques work	Trivially exploitable
User Population	Internal users only	Partner/B2B access	Public consumer access
Account Value	Standard user accounts	Elevated privileges	Admin/financial accounts
Data Sensitivity	Public data	Internal confidential	PII/financial/regulated
Compensating Controls	MFA + monitoring + rate limiting	Partial controls	No compensating controls

Risk Score = Sum of factors (5-15 range)

5-7: Low priority, standard remediation timeline
8-11: Medium priority, expedited remediation
12-15: High priority, immediate remediation required

Remediation SLAs

Based on risk score, establish remediation timelines:

Risk Level	Score Range	Remediation SLA	Escalation Path
Critical	13-15	24-48 hours	CISO, incident response
High	10-12	7 days	Security leadership
Medium	7-9	30 days	Security team
Low	5-6	90 days	Standard backlog

These SLAs must be enforced through security gates and executive reporting. When SLAs are not met, root causes include a lack of developer capacity, lack of ownership, or a problem with the security gate process itself.

3. Compliance Mapping

There are many implications of authentication vulnerabilities with respect to various compliance frameworks.

PCI-DSS Requirements

For organizations processing payment card data:

Requirement	Authentication Relevance
8.2	User identification and related accounts strictly managed throughout lifecycle
8.3	Strong authentication for users and administrators established and managed
8.3.4	Invalid authentication attempts lock out user ID after 10 or fewer attempts
8.3.6	Passwords meet minimum complexity (12+ characters, numeric and alphabetic)
8.3.9	Passwords changed every 90 days OR dynamic security posture analysis used
8.4.1	MFA for non-console administrative access into the CDE
8.4.2	MFA for all access into the CDE
8.5.1	MFA systems cannot be bypassed by any user

Additionally, PCI DSS 4.0.1 has enhanced requirements for MFA and flexibility in password rotation when MFA is used. The vulnerabilities in authentication within cardholder data environments are considered compliance breaches and may attract heavy fines, additional costs per transaction, or even denial of payment processing services.

SOC 2 Trust Services Criteria

The SOC 2 framework uses the 2017 Trust Services Criteria with 2022 revised points of focus. Several Common Criteria (CC) directly address authentication controls:

CC6.1 (Logical and Physical Access Controls): The entity implements logical access security software, infrastructure, and architectures over protected information assets. This includes user identification and authentication, network segmentation, and encryption.

CC6.2 (User Registration and Authorization): New internal and external users must be registered and authorized before receiving system credentials and access. This covers the provisioning lifecycle.

CC6.3 (Access Management): Access to data, software, functions, and protected information assets is authorized, modified, or removed based on roles, responsibilities, or system design changes. This supports role-based access control and least privilege principles.

CC6.6 (External Threat Protection): Logical access security measures protect against threats from sources outside system boundaries, including boundary protection systems and additional authentication requirements for external access.

CC7.2 (Security Event Detection): The entity monitors and analyzes anomalies that could indicate malicious acts to determine whether they constitute security events. This includes authentication failures and suspicious access patterns.

SOC 2 auditors expect evidence of authentication policies, MFA implementation, session management controls, and authentication monitoring. Document your authentication architecture and demonstrate testing coverage.

GDPR Article 5(1)(f) states that personal data must be processed in a way that ensures appropriate security, including protection against unauthorized or unlawful processing. Article 32 specifies this by stating that controllers and processors must implement appropriate technical and organizational measures to ensure a level of security that is appropriate to the risk.

Authentication controls are used to ensure GDPR compliance:

Strong authentication ensures that personal data is not accessed by unauthorized users, thus ensuring data confidentiality
Session management controls prevent data from being exposed to unauthorized users
Logging and monitoring are used to ensure that data breaches are detected, thus ensuring data breach notification within 72 hours, as required by Article 33

Although GDPR does not specify the type of authentication controls to be used, it recommends the implementation of "appropriate" controls, depending on the level of risk assessed. Where personal data is being processed in systems that contain sensitive personal data, such as data classified under Article 9, MFA and risk-based authentication are best practices, considering the "state of the art" requirement under Article 32(1).

HIPAA Requirements

For the healthcare industry, the HIPAA Security Rule (45 CFR 164.312) outlines the technical safeguards that are necessary for the protection of electronic protected health information (ePHI):

Required Specifications:

164.312(a)(2)(i): Unique user identification: Assign a unique name and/or number that is used for identifying and tracking user identity.
164.312(d): Person or entity authentication: Implement procedures that verify that the person or entity seeking access to ePHI is the one claiming access.

Addressable Specifications:

164.312(a)(2)(iii): Automatic logoff: Implement electronic procedures that terminate sessions after a predetermined period of inactivity.
164.312(a)(2)(iv): Encryption and decryption: Implement mechanisms that encrypt and decrypt ePHI.

Supporting Standard:

164.312(b): Audit controls: Implement mechanisms that record and examine activity in information systems containing ePHI.

For the current version of the HIPAA regulations, the addressable specifications require implementation unless documented risk analysis justifies an alternative approach. MFA is increasingly expected for systems containing ePHI, particularly after high-profile healthcare breaches.

Note: The HHS proposed major changes to the HIPAA Security Rule in January 2025, which would eliminate the addressable specifications and require MFA on all systems containing ePHI.

Documentation for Auditors

We need to ensure that we have adequate documentation that proves authentication control measures, such as:

Password policy documents that meet NIST SP 800-63B requirements
Metrics on MFA implementation
Configuration of rate limiting and account lockout
Session management policy documents
Authentication monitoring and alerting rules
Penetration test results
Remediation of vulnerability reports

4. Security Architecture Controls

In addition to these coding changes, security architects are responsible for ensuring that infrastructure and process controls are in place to provide defense in depth.

Authentication Architecture Patterns

Centralized Identity Provider

Centralize all authentication using a single identity provider such as Okta, Azure AD, Auth0, or self-hosted solutions such as Keycloak. This provides many benefits, including standardized security policies, single point for MFA rollout, centralized logging and monitoring, reduced attack surface as there are fewer implementations to manage, and easier compliance auditing.

Zero Trust Authentication

Do not trust users simply because they are on the corporate network. All users should authenticate access. This model assumes that all users are compromised and limits the blast radius.

Passwordless Authentication

FIDO2/WebAuthn offers phishing-resistant authentication using public-key credentials stored on devices. Hardware Security Keys, such as Yubikey, are the strongest option. Platform Authenticators, such as Touch ID or Windows Hello, are also good options. Passwordless eliminates the largest attack surface: passwords.

MFA Strategy

Not all MFA is equal. We must rank these from strongest to weakest:

FIDO2/WebAuthn with hardware keys: Phishing-resistant, cryptographic.
FIDO2/WebAuthn with platform authenticator: Phishing-resistant, device-bound.
TOTP Authenticator Apps: Time-based codes, shared secret.
Push: Vulnerable to MFA fatigue attacks.
SMS OTP: Vulnerable to SIM swapping, SS7 attacks.

Stronger MFA should be used for higher-risk accounts. Admin accounts should use hardware keys. Users could use authenticator apps. Should not use SMS OTP on high-value accounts.

Session Architecture

Implement session management at the architecture level:

Token-based or Session-based: Using JWTs for authentication enables stateless authentication, but makes token revocation difficult. Server-side sessions with Redis enable immediate revocation. Many systems use a combination of short-lived tokens and refresh tokens.

Session Storage: Use Redis or equivalent for storing sessions across multiple instances of the application. Using in-memory sessions will not work if you scale horizontally.

Session Binding: Consider binding sessions to additional factors, and use step-up authentication if binding changes.

Network Controls

Web Application Firewall: Implement WAF rules to identify and prevent authentication attacks. This includes rules to detect brute force patterns, credential stuffing signatures, and attack tools.

Rate Limiting at Network Edge: Implement rate limiting at the load balancer or CDN level as a first-line defense. Application-level rate limiting can also be implemented.

IP Reputation: Implement IP reputation to prevent malicious IP addresses from making requests. Cloudflare and AWS WAF offer IP reputation data.

5. Security Program Integration

Authentication security needs to be integrated into the software development lifecycle and not added at the end.

Secure SDLC Integration Points

Requirements Phase: The security requirements define the authentication mechanism. This includes MFA requirements, session timeout requirements, and logging requirements.

Design Phase: The architecture reviews the authentication patterns. This includes reviewing the identity provider selection, session management selection, and token selection.

Development Phase: The developers are provided with approved authentication libraries and patterns.

Testing Phase: The SAST tools should include checks for hardcoded passwords, poor use of cryptography, and authentication anti-patterns. DAST tools probe for authentication vulnerabilities. Penetration testing includes authentication-specific test cases.

Deployment Phase: The authentication configuration should be verified against the security requirements.

Operations Phase: Authentication metrics should be monitored for anomalies. Incident response should be in place for authentication breaches.

Security Gates

The security gates follow the typical pattern of pre-commit, pull requests, the CI pipeline, and pre-production. For the authentication scenario, the key gate trigger points are as follows:

Hardcoded credentials identified through SAST scanning
Modifications to authentication or session management logic that are subject to mandatory security review
DAST test cases for authentication that are executed in the staging environment

A post is planned to discuss the topic "Creating Security Gates Across the SDLC," so in this post, the focus is on what is different for the authentication scenario.

Developer Training

While developer training is obviously necessary, the overall structure of the training program, including mandatory training, refreshers, CTFs, and the champions program, is the same for all vulnerability types and will be discussed in a separate post. For the case of authentication, the necessary training topics include the following:

The difference between password storage algorithms, including the appropriate usage of bcrypt vs. Argon2id.
Common session management pitfalls in Spring Security.
MFA implementation pitfalls including fatigue.
NIST SP 800-63B guidelines, which many developers are not familiar with.

6. Metrics and Measurement

It is essential for security architects to measure the effectiveness of the program. Anecdotal evidence is not enough; instead, metrics must be used to prove the value of the program to the executive team.

Vulnerability Metrics

The standard vulnerability metrics (MTTD, MTTR, Vulnerability Density, Exposure Window, Security Debt Ratio) apply to authentication just as they do to any vulnerability class. Rather than repeating those definitions here, a future dedicated post will cover the full AppSec metrics framework. Below we focus on the metrics that are unique or especially important for authentication.

Control Effectiveness Metrics

MFA Coverage: Percentage of users who have MFA enabled, grouped by user type (admin, regular, service accounts). Target 100% for admin accounts; define targets for other account types based on risk.

Password Policy Compliance: Percentage of users who have passwords that are in compliance. Track users who have passwords that have not been changed since password policy updates.

Rate Limiting Effectiveness: Percentage of brute-force attempts that were blocked by rate limiting. Track false positives (legitimate users who were blocked).

Session Security: Percentage of applications that have correct session configuration.

Operational Metrics

Authentication Success Rate: Normal baseline compared to current. Significant changes may indicate attack or other issues.

Lockout Volume: Volume of lockouts per day. Significant changes may indicate attack.

MFA Challenge Success Rate: Percentage of MFA challenges completed successfully. Low rates may indicate attack or other issues.

Password Reset Volume: Requests per day with normal baseline. Significant changes may indicate attack or other issues.

6.4 Business Risk Metrics

Exposure Window: Time that vulnerable code was accessible in production, weighted by risk score.

Exposure = Σ (Hours in Production × Risk Score)

Lower exposure indicates faster detection and remediation.

Authentication-Related Incidents: Number and severity of security incidents related to authentication. Track root causes to identify systemic issues.

Compliance Status: Percentage of authentication controls meeting compliance requirements. Track gaps and remediation progress.

7. Incident Response Considerations

In spite of the best prevention strategies, authentication-related security incidents will happen. Security architects must consider incident response.

Detection Indicators

Authentication attacks can be identified by:

High number of failed login attempts
Credential stuffing signatures (a high number of failed login attempts across many accounts)
Unusual locations and/or times of login attempts
Session anomalies (rapid creation of sessions, impossible travel)
Spikes in password reset attempts
MFA challenge failures and bypass attempts
User reports of unauthorized access

Response Procedures

Incident response for authentication follows the standard incident response lifecycle (identify, contain, eradicate, recover, lessons learned), which will be covered in a dedicated post. What makes authentication incidents distinct is the detection and the immediate response.

Immediate Actions (First Hour)

Validate that the incident is real, not a false positive
Determine the scope of the incident
Safeguard logs and evidence
Activate the response team
Evaluate whether immediate mitigating actions are needed

8. Organizational Considerations

Security architecture is not only about technology, but also about people and process.

Security Champions Program

A security champions program provides security expertise to application development teams. For authentication, security champions should be aware of password storage implementations, session management configurations, and multi-factor authentication patterns.

Vendor and Third-Party Risk

Authentication risks also extend to third-party components, and this includes:

Evaluating the security practices of identity provider vendors
Checking authentication library vendors for vulnerabilities
Including authentication in vendor security assessments
Monitoring for vulnerabilities in authentication dependencies

A vulnerability in a widely used authentication library will impact all applications using this library.

Stakeholder Communication

Communication with different stakeholders requires different messages:

For the developers: Technical details, code examples, and clear standards are required.

For the engineering leadership: The message should include details around the tech debt, the velocity of the issue, and the capability building.

For the executives: The message should include details around the business risk and compliance.

For the auditors: Documentation of the controls, testing coverage, and remediation evidence are required.

Although the message is different for different stakeholders, the security program remains the same.

9. Authentication Maturity Roadmap

Security architects should also create a roadmap for the improvement of authentication security in the future.

Maturity Levels

Level 1 - Basic

Password-only authentication
Password policy (length, complexity, etc.)
Session management with standard timeouts
Basic logging

Level 2 - Standard

Password policy compliant with NIST SP 800-63B
Rate limiting and account lockout
Breach database checking
Session security (HttpOnly, Secure, SameSite)
Authentication event logging and monitoring

Level 3 - Advanced

MFA available for all users
MFA required for elevated privileges
Risk-based authentication
Centralized identity provider
Real-time anomaly detection

Level 4 - Leading

Passwordless authentication (FIDO2/WebAuthn)
Hardware security keys for admin accounts
Continuous authentication
Zero trust model
Automated threat response

Prioritizing Improvements

Determine current maturity level and plan to improve it. The prioritization will be done based on risk assessment, i.e., addressing critical vulnerabilities, implementing basic controls, applying MFA to high-risk accounts, developing detection mechanisms, and finally, adding advanced features.

These levels will be built upon each other, and skipping any level will provide attackers an opportunity to take advantage of those weaknesses.

Wrapping Part 4

Authentication security is not just a coding problem; it's a security program problem that involves architecture, governance, process, and culture.

Security architects should think beyond vulnerabilities and consider systemic security controls. The aim should not be to manually fix all authentication security issues but to create a system that makes it difficult to introduce authentication vulnerabilities, detect vulnerabilities when they occur, and fix vulnerabilities when they occur.

Authentication is the front door to your application; build it strong and improve it systematically.

Command Palette