Your Login Page Is a Compliance Surface
Authentication isn’t just a security feature. Under GDPR, NIS2, and DORA, it’s a compliance requirement with specific architectural implications.
GDPR Article 32 demands “appropriate technical and organisational measures” to protect personal data. That includes controlling who gets access.
NIS2 explicitly requires multi-factor authentication for administrative access. DORA mandates strong authentication for financial sector applications.
Most applications still rely on passwords. That’s a problem. Passwords are phished, reused, and leaked in breaches. The 2024 Verizon DBIR attributed 31% of all breaches to credential-related attacks.
Passkeys (FIDO2/WebAuthn) adoption surged 412% in 2025. The direction is clear. Modern authentication eliminates the weakest link. Let’s walk through the patterns that satisfy both security and compliance.
Authentication Patterns, Ranked
FIDO2/WebAuthn Passkeys
The gold standard for 2026. Passkeys use public key cryptography. The private key never leaves the user’s device.
No shared secrets on your server. Nothing to phish. Nothing to leak.
Every major OS (Windows, macOS, iOS, Android) and browser (Chrome, Safari, Edge, Firefox) supports WebAuthn natively. The user experience is actually better than passwords: biometric scan or device PIN, and you’re in.
GDPR alignment: biometrics are processed on-device only. Your server never sees the fingerprint or face scan. Only a cryptographic assertion. This dramatically simplifies your DPIA obligations for authentication.
Implementation: use a WebAuthn library (SimpleWebAuthn for Node.js, py_webauthn for Python). Store public keys and credential IDs in your user table. Support credential registration and authentication ceremonies.
Limitation: not all users have FIDO2-capable devices yet. Offer passkeys as the primary method with fallback options.
OAuth 2.1 with PKCE
For applications that delegate authentication to an identity provider (Google, Microsoft, corporate SSO), OAuth 2.1 with PKCE (Proof Key for Code Exchange) is the standard.
OAuth 2.1 consolidates best practices from OAuth 2.0. PKCE is mandatory for all clients (not just public ones). Implicit grant is removed. Refresh token rotation is required.
Why this matters for compliance: you’re delegating authentication to a provider with (presumably) stronger security infrastructure. Your application never handles passwords. You reduce your attack surface.
Use OpenID Connect on top of OAuth 2.1 for authentication (OAuth alone is authorization only). Validate ID tokens. Don’t roll your own token validation.
Time-based One-Time Passwords (TOTP)
TOTP (Google Authenticator, Authy, 1Password) is still the most widely deployed MFA method. Easy to implement. Well understood. Resistant to replay attacks.
The trade-off: TOTP is phishable. A sophisticated attacker can proxy the login page and capture the OTP in real time.
For most SMB applications, the risk is acceptable. For high-value targets, passkeys are better.
Implementation: use a TOTP library. Generate a secret per user, display it as a QR code, verify 6-digit codes with a 30-second window and one-step tolerance.
Password + MFA (minimum baseline)
If you’re still using passwords, MFA is non-negotiable. NIS2 explicitly requires it for administrative access. Any system processing personal data should require MFA for all users with elevated privileges.
Password requirements under GDPR aren’t specified, but the EDPB expects “appropriate” measures. At minimum: no maximum length restrictions (allow passphrases), check against known breached passwords (HIBP API), bcrypt or Argon2 for hashing (never MD5 or SHA-256 without salt), rate-limit authentication attempts.
Session Management
Authentication doesn’t end at login. Session management is where many applications leak security.
Session tokens. Use cryptographically random tokens. Store them server-side or use signed JWTs with short expiration times. Never put session IDs in URLs.
Session expiration. Idle timeout: 15-30 minutes for sensitive applications. Absolute timeout: 8-12 hours regardless of activity. Re-authentication for sensitive operations (payment, account changes, data export).
Session revocation. When a user changes their password or reports a compromised account, invalidate all active sessions immediately. With JWTs, this requires a token blocklist or short-lived tokens with refresh rotation.
Concurrent sessions. Decide whether users can have multiple active sessions. If yes, provide a session management UI showing all active sessions with the ability to revoke any of them.
Consent for Authentication Data
Under GDPR, processing personal data for authentication typically falls under “legitimate interest” (Article 6(1)(f)) or “contract performance” (Article 6(1)(b)). You don’t usually need explicit consent for the login itself.
But you do need to tell users what authentication data you collect and retain. Your privacy notice should cover: what identifiers you store (email, username, device fingerprints), how authentication events are logged, how long session data is retained, and whether third-party identity providers are involved.
If you use biometric authentication, even device-based FIDO2, mention it in your privacy notice. The biometrics stay on-device, but transparency builds trust.
Audit Logging for Authentication
Every authentication event should be logged. Successful logins, failed attempts, password changes, MFA enrollment, session creation and destruction. These logs serve two purposes: security incident detection and compliance evidence.
Log entries should include: timestamp, user identifier (not password), IP address (consider GDPR implications of IP logging), authentication method used, success/failure status, and failure reason.
Do not log passwords, even hashed ones, in your authentication logs. Do not log full session tokens.
Retain authentication logs for at least 12 months. Align with your NIS2 and GDPR retention requirements.
Architecture for Multi-Application Environments
If you run multiple applications, centralize authentication. Single sign-on (SSO) through an identity provider (Keycloak, Auth0, Azure AD, AWS Cognito) gives you one place to enforce MFA, manage sessions, and audit access.
Benefits for compliance: one set of authentication policies, one audit trail, one place to disable a compromised account across all applications.
Implement SSO using SAML 2.0 or OpenID Connect. Prefer OpenID Connect for new implementations (SAML is XML-heavy and harder to debug).
For the broader security and compliance context, see our Security by Design guide. And for the full EU regulatory landscape, our pillar guide on EU compliance for software teams covers how authentication fits into the bigger picture. If your authentication flows handle sensitive data, our GDPR architecture guide covers the privacy layer.
Building authentication for a GDPR-compliant application? Let’s design it right from the start. We implement secure, regulation-ready authentication that your team and your auditors will appreciate.
