SEC-1 Tech Due Diligence

Tech Due Diligence SEC-1: Authentication and Session Management

What This Control Requires

The assessor evaluates the authentication system design, including identity provider integration, password policies, multi-factor authentication support, session management, and protection against common authentication attacks such as credential stuffing and brute force.

In Plain Language

Your authentication system is the front door to everything you build. If it falls over, nothing else matters - data breaches, account takeovers, and total loss of customer trust follow quickly.

In a tech DD review, we look at how you handle identity: are you using a proven identity provider or did you roll your own? What password hashing algorithm is in play (bcrypt, scrypt, Argon2), and is it properly configured? Is multi-factor authentication available, and how many users actually have it turned on? We examine session management - token-based or session-based, expiration policies, revocation capabilities - and check your defences against brute force, credential stuffing, and session fixation. OAuth/SSO implementation quality and account recovery flows also come under scrutiny.

Custom-built authentication is a significant risk signal. Authentication is notoriously hard to get right, and we strongly favour established identity providers (Auth0, Keycloak, Cognito, Firebase Auth) unless your team has deep security expertise and a genuinely compelling reason to build from scratch.

How to Implement

Start with an established identity provider rather than building authentication yourself. Services like Auth0, Keycloak, Cognito, or Firebase Auth handle the hard parts - password hashing, MFA, account lockout, session management - and keep pace with evolving best practices.

If you do build custom authentication, get the fundamentals right: hash passwords with Argon2id, bcrypt (cost factor 12+), or scrypt. Never store passwords in plain text or with reversible encryption. Set a minimum password length of 12+ characters but avoid character class requirements that push users toward predictable patterns. Lock accounts after repeated failed attempts.

Make multi-factor authentication available to every user. Support TOTP (authenticator apps), WebAuthn/FIDO2 (hardware keys), and SMS as a fallback. Track adoption rates and mandate MFA for all administrative accounts at a minimum.

For session management, use cryptographically secure random session identifiers. Set sensible expiration times (shorter for sensitive operations) and build in session revocation so users can sign out from all devices. Protect session tokens with HttpOnly, Secure, and SameSite cookie flags, and implement CSRF protection for cookie-based sessions.

Layer in attack protection: rate-limit login endpoints, detect and block credential stuffing (using IP reputation, device fingerprinting, and anomaly detection), implement account lockout with user notification, and monitor for unusual authentication patterns.

For account recovery, make password reset tokens single-use, time-limited, and cryptographically random. Skip security questions entirely. If an account has MFA enabled, require MFA verification before allowing a password reset.

For B2B customers, support enterprise SSO via SAML and OIDC so they can integrate with their corporate identity provider.

Evidence Your Auditor Will Request

Authentication system architecture documentation
Password hashing configuration (algorithm, parameters)
MFA implementation and adoption rate metrics
Session management configuration (expiration, flags, revocation)
Rate limiting and brute force protection configuration

Common Mistakes

Custom-built authentication with security vulnerabilities
Weak password hashing (MD5, SHA-1, or bcrypt with low cost factor)
MFA not available or not enabled for administrative accounts
Session tokens lack HttpOnly/Secure flags or have excessive lifetimes
No rate limiting on authentication endpoints

Related Controls Across Frameworks

Framework	Control ID	Relationship
ISO 27001	A.8.5	Related
SOC 2	CC6.1	Related

Frequently Asked Questions

Is a custom authentication system always a red flag?

Not automatically, but it does raise the bar. If you built custom auth, expect it to be examined closely for implementation flaws. Teams using established identity providers get battle-tested security without needing to maintain that expertise in-house. Custom auth is really only justified when you have strong security skills on the team and specific requirements that existing providers genuinely cannot meet.

What MFA adoption rate is expected?

Administrative and privileged accounts should be at 100%, no exceptions. For regular users, having MFA available is the baseline - actively promoting it and getting adoption above 30% signals a healthy security culture. Some products mandate MFA for everyone, which is the gold standard.

Track Tech Due Diligence compliance in one place

AuditFront helps you manage every Tech Due Diligence control, collect evidence, and stay audit-ready.

Start Free Assessment