The mobile app authentication best practices question is the single hardest one to answer well in mobile application security, because the answers that work for web applications fail in subtle ways on mobile devices. The browser does most of the heavy lifting in a web application's authentication flow — cookie handling, redirect orchestration, session storage with reasonable defaults. The mobile application has to build the equivalent capability itself, against a platform where the application binary is in the attacker's possession, where biometric prompts are often treated as authentication when they should be treated as presence assertions, where token storage decisions made at design time bind the application's security posture for its entire deployment, and where the OAuth flow patterns appropriate for confidential web clients are categorically wrong for public mobile clients. This guide walks the best practices for secure authentication in mobile apps from a developer's perspective, anchored to the OWASP mobile application security verification standard (MASVS) V4 chapter that defines the verification requirements at L1, L2, and L2+R levels. The broader mobile security context — platform security primitives, the OWASP Mobile Top 10 2024, the complete attack surface — is covered in the mobile app security pillar; this deep dive focuses on the authentication subset specifically.

Why Mobile Authentication Is Different From Web Authentication

The web authentication threat model assumes a hostile network, a relatively trusted browser, and a server-controlled session lifecycle. The browser handles cookie security (HttpOnly, Secure, SameSite), enforces same-origin policy, and limits JavaScript access to authentication artifacts in ways the application benefits from without writing the enforcement itself. The session lives on the server; the cookie is just a session identifier the server can revoke at any time. The attack surface the developer worries about is mostly between the browser and the server — TLS configuration, CSRF protection, session fixation, the cookie attributes — with a smaller secondary surface of XSS-driven cookie theft.

The mobile authentication threat model is different in three operationally significant ways. First, the application binary is on the attacker's device. Anything embedded in the binary is visible to a reverse engineer with the IPA or APK file — no secrecy guarantee on credentials, API keys, or authentication endpoint URLs. Second, the device's secure storage primitives are part of the application's authentication design rather than a separate platform concern. Where a web application stores session state on the server and uses a cookie identifier, a mobile application typically stores tokens locally in platform-secure storage (iOS Keychain, Android Keystore) with accessibility classes the developer has to choose deliberately. Third, the application runs as a public client in OAuth terms — it cannot hold a client secret because the binary is reverse-engineerable. The OAuth flows appropriate for confidential server-side clients are the wrong choice for mobile; the authorization code flow with PKCE is the only OAuth 2.1-compliant flow for mobile public clients.

The fourth difference, less talked about but operationally consequential: the mobile application's authentication lifecycle is fundamentally session-based but with a much longer typical session than web. A user authenticates once, the application stores refresh tokens, and re-authentication happens transparently for months. The web equivalent — keeping users logged in across browser sessions — is more conservative because cookies expire, browser updates clear state, and users routinely log out. Mobile users expect "stay logged in" as the default behavior; the application has to make refresh-token storage and rotation work correctly across this long lifecycle, with the application binary continuously in the attacker's possession.

The Authentication Methods Spectrum

The mobile authentication landscape spans several distinct methods, each with appropriate use cases, security properties, and implementation patterns. Understanding which method fits which scenario is the first design decision in any mobile authentication flow.

Password-based authentication. The legacy default. Username and password collected in-app, sent to the server, verified against a hash. The pattern has been declining as a primary authentication factor since multi-factor expectations became baseline, but it remains the fallback for almost every mobile authentication flow because some users have to recover access when other factors fail. The implementation pitfalls cluster around password handling — never store the password on the device, never log it, never transmit it outside the authentication endpoint, never send it through analytics or crash reporters. Server-side, the hashing requirements are the same as web (Argon2id or scrypt with appropriate cost parameters, never SHA-1 or unsalted MD5).

OTP and TOTP. One-time passwords delivered via SMS, email, or generated by an authenticator app (TOTP). SMS-OTP is the weakest mobile authentication factor in production use — SIM swap attacks have made SMS unreliable for high-security applications — but remains the most-deployed second factor for consumer applications because of its broad device support. TOTP via authenticator apps (Google Authenticator, Authy, 1Password, Apple Passwords) provides substantially stronger security and should be the preferred second factor for new applications. The implementation pattern: enrollment generates a shared secret stored in the user's authenticator app and the server, subsequent authentications transmit the TOTP-derived code which the server verifies against its stored secret.

Biometric authentication. Face ID, Touch ID, fingerprint readers, in-display fingerprint sensors. The most-misused mobile authentication primitive in the industry. Biometric prompts authenticate the device — they confirm that the person presenting biometric data is the device's enrolled user — but they do not authenticate against the application's identity provider. A biometric "approval" in the application is a presence assertion (the enrolled device user is here right now) layered on top of a previously-established authentication session. The application that treats a biometric prompt as authentication itself, without the underlying session having been established through a real authentication flow, has a security architecture with no actual authentication despite the biometric prompts in the UI.

Hardware-backed authentication. WebAuthn/FIDO2 credentials, passkeys, hardware security keys. The strongest mobile authentication factor available in 2026 and the direction the industry is moving for high-security applications. iOS supports passkeys natively from iOS 16+, with cross-device sync via iCloud Keychain. Android supports passkeys from Android 9+ with Google Password Manager sync. Hardware security keys (YubiKey, SoloKey) integrate via NFC or USB-C on mobile devices. The applications that have migrated to passkey-first authentication report substantially lower account takeover rates than password-based authentication; the migration cost is moderate because the underlying WebAuthn protocol is well-defined and platform support is mature.

OAuth/OIDC federated authentication. Sign in with Apple, Sign in with Google, Sign in with Facebook, enterprise SSO via OIDC. The application delegates authentication to a federated identity provider; the user authenticates at the IdP through whatever flow the IdP supports (which may itself include passwords, biometrics, MFA), and the application receives an ID token confirming the user's identity. The pattern reduces the application's authentication attack surface — no password handling, no credential storage — at the cost of a dependency on the federated identity provider. The OAuth/OIDC implementation patterns are covered in the OIDC vs SAML vs OAuth comparison; the mobile-specific consideration is that the application is always a public client and must use authorization code flow with PKCE.

The best security authentication methods for mobile apps in 2026 increasingly combine these factors rather than treating them as alternatives. Passkey as the primary authentication factor, biometric prompt for transaction confirmation within an existing session, OAuth federation for new-user signup with progressive enrollment of passkey for subsequent logins. The single-factor-only application is increasingly the exception rather than the norm.

MASVS V4 Authentication Requirements Walked

The OWASP Mobile Application Security Verification Standard (MASVS) V4 chapter on Authentication and Session Management defines the verification requirements that anchor a defensible mobile authentication implementation. Walking the chapter at the operational depth a verification effort actually requires.

V4.1 — The app uses appropriate authentication protocols. The application uses standards-based authentication protocols (OAuth 2.1 with PKCE, OIDC, WebAuthn) rather than rolling its own credential exchange. The negative pattern is custom protocols that send credentials directly in the application's API calls — these almost always have subtle bugs that standards-based protocols have already debugged away.

V4.2 — Sensitive operations require step-up authentication. The application's privileged operations (account changes, financial transactions, settings that affect security posture) require fresh authentication or biometric confirmation beyond the long-lived session. The negative pattern is treating "authenticated session" as permission to do anything within that session indefinitely.

V4.3 — Authentication tokens are stored in platform-secure storage. Refresh tokens and long-lived authentication artifacts go in iOS Keychain or Android Keystore with appropriate accessibility classes. Never in NSUserDefaults, SharedPreferences, plain SQLite, or files in the application's documents directory.

V4.4 — Tokens expire and rotate. Access tokens expire on a short timeline (15-60 minutes typical); refresh tokens rotate on use (the authorization server issues a new refresh token alongside the new access token and invalidates the previous one). Detection of a previously-invalidated refresh token presentation indicates token theft and should trigger session-wide revocation.

V4.5 — Biometric authentication is bound to cryptographic operations. Where biometric authentication gates access to cryptographic operations (signing, decryption), the cryptographic key is generated with user-authentication-required flags so the platform refuses to use the key without successful biometric verification. The negative pattern is treating biometric "success" as a boolean returned by the application code, which can be bypassed via runtime hooking or modified clients.

V4.6 — The application requires re-authentication after extended inactivity. The session expires after a defined period of inactivity, with re-authentication required to resume. The duration depends on the application's sensitivity — minutes for banking, hours for consumer applications, days for entertainment apps. The pragmatic default is to lean shorter and let users opt into longer sessions explicitly.

The full MASVS V4 chapter has additional requirements covering federated authentication, multi-factor enrollment, and account recovery; the requirements above are the ones most commonly missed in production audits. Verification at L1 covers V4.1-V4.6; L2 adds stricter evidence requirements; L2+R adds resistance requirements around binding tokens to the device in ways that resist client compromise.

Token Storage Deep Dive — iOS Keychain and Android Keystore

The single most consequential mobile authentication decision is where to store the authentication tokens. The correct answer is platform-secure storage; the implementation details are where most bugs live.

iOS Keychain — accessibility classes that matter. The Keychain offers several accessibility classes that determine when stored items are decryptable. The classes worth knowing:

// Strictest — only when device unlocked AND tied to this device
// (won't restore to another device, requires biometric on devices with one)
kSecAttrAccessibleWhenUnlockedThisDeviceOnly

// Strict — only when device unlocked, tied to this device
kSecAttrAccessibleWhenUnlockedThisDeviceOnly

// Less strict — after first unlock since boot, tied to this device
kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly

// Avoid — works always, even on locked device (legacy)
kSecAttrAccessibleAlways  // DEPRECATED, do not use

The pragmatic default for authentication tokens: kSecAttrAccessibleWhenUnlockedThisDeviceOnly. The token is available only when the device is unlocked (refusing access from background services after a screen lock) and only on this specific device (refusing iCloud Keychain sync of authentication artifacts to other devices). The pattern aligns with the security posture most authentication flows expect.

The additional Keychain feature worth using: access control with biometric requirement. The Keychain item can require biometric authentication before each access, separately from the device being unlocked:

var error: Unmanaged<CFError>?
let accessControl = SecAccessControlCreateWithFlags(
    nil,
    kSecAttrAccessibleWhenUnlockedThisDeviceOnly,
    .biometryCurrentSet,
    &error
)
let query: [String: Any] = [
    kSecClass as String: kSecClassGenericPassword,
    kSecAttrAccount as String: "auth_token",
    kSecAttrService as String: Bundle.main.bundleIdentifier!,
    kSecAttrAccessControl as String: accessControl!,
    kSecValueData as String: tokenData,
]
let status = SecItemAdd(query as CFDictionary, nil)

The .biometryCurrentSet flag invalidates the stored item if biometric enrollment changes (a new fingerprint registered, Face ID re-trained) — a useful defense against attackers who gain device access and enroll their own biometric.

Android Keystore — hardware-backed keys and user authentication. Android Keystore generates and stores cryptographic keys; for authentication, the typical pattern is to encrypt the refresh token with a Keystore-managed key. The key properties:

val spec = KeyGenParameterSpec.Builder(
    "auth_token_key",
    KeyProperties.PURPOSE_ENCRYPT or KeyProperties.PURPOSE_DECRYPT
)
    .setBlockModes(KeyProperties.BLOCK_MODE_GCM)
    .setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
    .setUserAuthenticationRequired(true)
    .setUserAuthenticationParameters(
        30, // valid for 30 seconds after auth
        KeyProperties.AUTH_BIOMETRIC_STRONG
    )
    .setInvalidatedByBiometricEnrollment(true)
    .setIsStrongBoxBacked(true)
    .build()

val keyGenerator = KeyGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_AES,
    "AndroidKeyStore"
)
keyGenerator.init(spec)
keyGenerator.generateKey()

The properties worth highlighting. setUserAuthenticationRequired(true) requires biometric or PIN authentication before the key can be used. setInvalidatedByBiometricEnrollment(true) destroys the key if biometric enrollment changes. setIsStrongBoxBacked(true) places the key in the StrongBox secure element on devices that have one (Pixel 3+, recent Samsung flagships, increasingly the default on premium Android in 2026). setUserAuthenticationParameters(30, AUTH_BIOMETRIC_STRONG) requires strong biometric (Class 3) and constrains the validity window to 30 seconds after authentication.

For non-cryptographic authentication artifacts, Android's EncryptedSharedPreferences provides a higher-level API that internally uses Keystore-managed keys. The pragmatic pattern is Keystore for cryptographic keys, EncryptedSharedPreferences for non-cryptographic sensitive values that need to persist across application launches.

Biometric as Presence Assertion vs Authentication Factor

The mental model that produces the most-correct mobile authentication code is to treat biometric prompts as presence assertions rather than authentication events. A biometric prompt confirms one of two propositions: either "the device's enrolled biometric is currently being presented" (the user is here right now) or "the device's enrolled biometric was presented to unlock this cryptographic key" (a previously-established authentication is being unlocked for use now). It does not confirm "this user has authenticated against the identity provider" — that authentication has to happen separately, typically when the user first signs into the application.

The correct integration pattern: the user signs in once through a real authentication flow (OAuth/OIDC with the identity provider, password + MFA, passkey ceremony, or whatever the application's primary authentication is). The application receives tokens that confirm the user's identity. The application stores the refresh token in platform-secure storage, with the storage gated by biometric authentication. On subsequent application launches, the biometric prompt unlocks access to the stored refresh token, which is then exchanged for a fresh access token against the identity provider. The biometric prompt is a presence assertion that unlocks the previously-established authentication; it is not authentication itself.

The incorrect pattern that ships in production despite the documentation warning against it: the application uses biometric "success" as a boolean returned by the platform's biometric API, then assumes the user is authenticated based on that boolean. The pattern fails because the boolean can be bypassed — a modified client returns true regardless of actual biometric input; a hooking framework like Frida intercepts the API call and returns success without invoking the platform's biometric subsystem at all. The defense is to bind biometric authentication to cryptographic operations as the MASVS V4.5 requirement specifies — the cryptographic key is unusable without successful biometric verification at the platform level, which cannot be bypassed by application-level hooking.

Device Binding — App Attest, Play Integrity, mTLS-Bound Tokens

Server-side validation of mobile authentication has a problem the web equivalent does not: the server cannot tell whether the requesting client is the legitimate mobile application or a tool reverse-engineered from the application's binary. The defenses cluster under the term device binding — making the authentication artifacts usable only from the legitimate client on the legitimate device.

iOS App Attest. Apple's attestation API ties cryptographic assertions to the application's bundle ID and the device's secure enclave. The server validates assertions against Apple's CA; assertions that don't validate indicate the request is not coming from a genuine App Store binary on a genuine Apple device. The integration pattern: on first launch, the application generates an attestation key via App Attest, sends the attested key to the server, and the server stores the key as bound to this user's account. On subsequent sensitive operations, the application generates an assertion over the request payload, the server validates it, and the operation proceeds only if validation passes.

Android Play Integrity API. The Android equivalent (succeeding the deprecated SafetyNet) provides an integrity verdict the server can validate via Google's API. The verdict includes device integrity (genuine device with Play Protect), application integrity (binary matches what was uploaded to Play Console), and account information (whether the installing Google account is recognized). The server makes decisions based on the verdict — allow, refuse, or require additional verification for less-than-strong integrity results.

mTLS-bound access tokens. The strongest device binding pattern. The mobile application authenticates to the authorization server with mutual TLS using a device-specific certificate; the issued access token is bound to the certificate. The resource server validates that the same certificate is presented when the token is used. A stolen access token is unusable from any host other than the original mTLS-authenticated device. The pattern requires PKI infrastructure to issue and revoke device certificates, which adds operational complexity, but provides the strongest available defense against token theft for high-security applications (banking, payment processing).

The pragmatic choice depends on the application's sensitivity. Consumer applications typically run App Attest and Play Integrity as defense-in-depth without mTLS. Enterprise applications and payment-handling applications increasingly add mTLS-bound tokens for the additional resistance against client compromise.

Refresh Token Rotation and Session Lifecycle

Mobile authentication's long-lived session pattern depends on refresh tokens that survive across application launches, device reboots, and network interruptions. The session lifecycle that works in production:

Access token: short-lived, in memory only. The access token is the credential the application presents to API endpoints. It expires on a short timeline — 15 minutes is a common default, 60 minutes is the outer reasonable bound. The access token lives in application memory, never persisted to storage. When the application backgrounds or the access token expires, the next API call triggers a refresh using the stored refresh token.

Refresh token: long-lived, in platform-secure storage, rotated on use. The refresh token persists across application launches in Keychain (iOS) or Keystore-encrypted SharedPreferences (Android) with biometric-gated access. Every use of the refresh token rotates it — the authorization server issues a new refresh token alongside the new access token and invalidates the previous one. The pattern bounds the consequence of refresh token theft: a stolen refresh token used by an attacker invalidates the legitimate refresh token, which causes the next legitimate refresh attempt to fail, which signals the theft to the application and the server.

Token theft detection. When the authorization server sees a presentation of a previously-invalidated refresh token, it indicates one of two scenarios: the legitimate client failed to record the rotated token (a bug worth investigating but not a security event), or the previous refresh token leaked to an attacker who is using the leaked version. The defensive response is to revoke the entire token chain — invalidate the current refresh token, force re-authentication, and log the event for analysis.

Session timeout policies. Even with refresh tokens, applications should enforce session timeout based on user behavior. The pattern: a "soft" timeout that triggers biometric re-confirmation after extended inactivity (say, 24 hours), and a "hard" timeout that forces full re-authentication after a longer period (30 days for consumer applications, 7 days for sensitive applications, 24 hours for banking). The soft timeout uses the existing refresh token; the hard timeout invalidates the refresh token and requires the user to authenticate again through the primary authentication flow.

Authentication Failure Modes From Real Pentests

The failure modes that show up in real-world mobile authentication pentest reports cluster around six patterns. Each maps to a MASVS V4 requirement; the defense pattern for each is established.

Tokens in insecure storage. The single most common finding. Refresh tokens or session identifiers stored in NSUserDefaults, SharedPreferences, plain SQLite databases, or files in the application's documents directory. The attacker with device access (jailbroken iOS, rooted Android) extracts the tokens trivially and impersonates the user against the server. The fix is Keychain/Keystore as covered above.

Biometric as standalone authentication. The second-most-common finding. The application uses biometric "success" as authentication itself, with no underlying server-validated session. Bypassing the biometric prompt (via Frida hooks, modified clients, or platform-level vulnerabilities) gives full application access. The fix is binding biometric to cryptographic operations as MASVS V4.5 requires.

Refresh tokens that don't rotate. Long-lived refresh tokens that the authorization server reissues without rotation, creating a token that remains valid indefinitely from the moment of theft until the user manually revokes it. The fix is mandatory refresh token rotation on use with theft-detection logic on previously-invalidated token presentation.

JWT signature validation bypassed. The application receives JWT-format tokens and uses the claims without validating the signature, or validates the signature using the algorithm specified in the JWT header rather than the algorithm fixed at the application level. The classic JWT algorithm confusion attack. The JWT vulnerabilities guide covers the full taxonomy.

Authorization confused with authentication. The application reads claims from an OAuth access token to determine identity. The access token does not encode identity; it encodes authorization. Using it as an authentication artifact is a misuse covered in the OIDC vs OAuth comparison. The fix is using ID tokens (in OIDC scenarios) or UserInfo endpoint calls (in pure-OAuth scenarios) for identity.

Account recovery weaker than primary authentication. The application has strong primary authentication (passkey, biometric-bound tokens) but weak account recovery (email link with no MFA, security question, SMS OTP only). The attacker bypasses the primary authentication by triggering account recovery. The fix is recovery flows that are at least as strong as primary authentication — recovery should require multiple factors equivalent in strength to the primary login flow.

How to Secure Mobile Apps — Authentication Checklist

For developers asking how to secure mobile apps at the authentication layer specifically, the operational checklist that produces a defensible posture in 2026:

Use standards-based authentication protocols (OAuth 2.1 with PKCE for federated, WebAuthn/passkeys for primary, never custom credential exchange). Store all authentication tokens in platform-secure storage (Keychain on iOS with kSecAttrAccessibleWhenUnlockedThisDeviceOnly, Keystore on Android with hardware backing and user-authentication-required keys). Treat biometric prompts as presence assertions, not authentication events — bind biometric to cryptographic operations rather than checking a boolean. Implement refresh token rotation on use with theft detection on previously-invalidated token presentation. Use device attestation (App Attest, Play Integrity) to bind authentication artifacts to the legitimate client; for high-security applications, layer mTLS-bound access tokens on top. Enforce session timeout policies appropriate to the application's sensitivity (soft and hard timeouts). Make account recovery at least as strong as primary authentication. Validate every JWT signature against the algorithm fixed at the application level, not the algorithm claimed in the token header. Use ID tokens (not access tokens) for identity claims.

The integration with the secure mobile app development lifecycle — covered in the secure SDLC pillar — embeds these requirements as MASVS V4 verification artifacts during the testing phase. The mobile app development security best practices for authentication are not a separate program from the broader application security work; they are the authentication-specific verification activities within an MASVS-anchored mobile security program. The mobile application development security best practices framing — common in procurement security questionnaires — maps onto the same MASVS verification requirements with vocabulary alignment.

For the broader mobile security context — platform security primitives, OWASP Mobile Top 10 2024, complete attack surface, and the integration with iOS/Android-specific platform features — the mobile app security pillar covers the landscape this deep dive sits inside. For the cross-platform authentication standards (OAuth 2.1, OIDC, SAML), the OIDC vs SAML vs OAuth 2.0 comparison walks the protocol-level decisions this mobile-specific implementation inherits from.

Mobile app authentication: questions developers ask

What are mobile app authentication best practices in 2026?

Use standards-based protocols (OAuth 2.1 with PKCE, WebAuthn/passkeys), store tokens in platform-secure storage (Keychain / Keystore), treat biometrics as presence assertions bound to cryptographic operations rather than authentication events, rotate refresh tokens on use with theft detection, use device attestation (App Attest, Play Integrity) to bind tokens to the legitimate client, enforce session timeout policies, make account recovery as strong as primary authentication.

How do I secure mobile apps at the authentication layer?

Anchor verification to MASVS V4 — the OWASP Mobile Application Security Verification Standard chapter on Authentication and Session Management. The chapter defines requirements at L1, L2, and L2+R levels. Implementation: standards-based protocols, platform-secure token storage, biometric bound to crypto operations, rotating refresh tokens with theft detection, device attestation. Avoid biometric as standalone authentication, tokens in insecure storage, and access tokens used as identity claims — these are the most common findings in real mobile pentest reports.

What are the best security authentication methods for mobile apps?

Passkeys (WebAuthn/FIDO2) are the strongest available primary factor in 2026 — iOS 16+ and Android 9+ support them natively. OAuth/OIDC federated authentication for delegated identity (Sign in with Apple, Sign in with Google, enterprise SSO). TOTP for second factor (preferred over SMS OTP). Biometric as a presence assertion within an established session, not as standalone authentication. Most mature applications combine methods — passkey primary, biometric for transaction confirmation, federated for new-user signup.

Where should I store mobile authentication tokens?

iOS: Keychain with kSecAttrAccessibleWhenUnlockedThisDeviceOnly accessibility class and access control requiring biometric. Android: Keystore for cryptographic keys (with setUserAuthenticationRequired true and StrongBox backing where available), EncryptedSharedPreferences for non-cryptographic sensitive values. Access tokens in memory only; refresh tokens persisted in platform-secure storage with biometric-gated access. Never in NSUserDefaults, SharedPreferences (unencrypted), plain SQLite, or files in the application documents directory.

Is biometric authentication enough for a mobile app?

No, not as standalone authentication. Biometric prompts authenticate the device — they confirm the device's enrolled biometric is currently being presented. They do not authenticate against the application identity provider. The correct pattern is real authentication once (password, passkey, OAuth federation), then biometric as a presence assertion that unlocks access to the previously-established authentication's tokens. Treating biometric "success" as authentication itself fails when attackers bypass the biometric prompt at the platform level or via runtime hooking.

Should mobile apps rotate refresh tokens?

Yes. Refresh token rotation on use is the OAuth 2.1 baseline — the authorization server issues a new refresh token alongside the new access token and invalidates the previous one. The pattern bounds the consequence of refresh token theft: a stolen refresh token invalidates the legitimate refresh token, the legitimate client's next refresh attempt fails, signaling the theft. The server-side detection of a previously-invalidated refresh token presentation should trigger session-wide revocation.

What is the OWASP MASVS V4 chapter about?

MASVS V4 is the Authentication and Session Management chapter of the Mobile Application Security Verification Standard. It contains the verification requirements that define a defensible mobile authentication implementation — appropriate authentication protocols, step-up authentication for sensitive operations, tokens in platform-secure storage, token expiration and rotation, biometric bound to cryptographic operations, and re-authentication after extended inactivity. V4 verification at L1 covers the baseline; L2 adds stricter evidence; L2+R adds resistance requirements for high-value applications.

Originally published at SecureCodingHub.