After KeyPermanentlyInvalidatedException: silent key re-enrollment or forced server re-authentication?

Direct Answers

1. Defensible approach: Treat the exception as a trigger for step-up authentication before generating a new key and re-binding the refresh token. Silent re-enrollment is not defensible for mid-sensitivity apps because the platform cannot distinguish benign lock-screen changes from compromise.
2. Server-side mitigation: Yes. The server should treat any refresh-token use that follows a client-reported authentication failure (or an unexpected token presentation) as a signal to require step-up authentication or full re-authentication, regardless of the client's stated reason.
3. Per-use vs. validity window: Using setUserAuthenticationParameters(0, false) (per-use auth) significantly reduces risk. A validity window > 0 allows a regenerated key to be used without fresh user confirmation during that window, undermining the security model.

Why Step-Up Authentication Is the Middle Ground

When KeyPermanentlyInvalidatedException occurs, the original key is destroyed. The app must create a new key to continue encrypting or decrypting the refresh token. The critical question is who authorizes that new key.

If the app silently generates a new key and re-wraps the stored token, an attacker who triggered the invalidation (for example, by enrolling their own fingerprint on a stolen device) gains immediate access to a usable encryption key. The platform provides no signal to differentiate this from a legitimate user changing their lock screen.

Requiring step-up authentication—prompting the user for biometric or device credential before creating the replacement key—ensures the person authorizing the new key is the same person who just authenticated. This matches the original threat model: no usable credential without fresh user authentication.

Server-Side Defense Without Client Disclosure

The server does not need to know why the key was invalidated. It only needs to observe that a refresh token is being presented after the client reported an authentication failure, or after an unexpected token rotation. A simple rule works:

• The client catches KeyPermanentlyInvalidatedException, prompts step-up auth, creates a new key, re-wraps the token, and presents the token with a rotation or re-attestation signal.
• The server sees that signal and requires step-up authentication (for example, password plus a second factor) before issuing a new access token.

This adds a defensive layer even if the client is compromised or the exception is suppressed locally.

Impact of setUserAuthenticationParameters

For mid-sensitivity apps, per-use authentication is the safer default. The usability cost is one additional biometric prompt at the moment of key rotation, which should be rare.

Verification Steps (API 30+, TEE/StrongBox)

1. Create a key with setUserAuthenticationRequired(true), setInvalidatedByBiometricEnrollment(true), and setUserAuthenticationParameters(0, false).
2. Encrypt a test payload.
3. Enroll a new fingerprint in system settings.
4. Attempt decryption and observe KeyPermanentlyInvalidatedException.
5. Prompt step-up auth, generate a new key, and re-encrypt the payload; verify decryption works only after fresh auth.
6. Repeat with a 30-second validity window and confirm the new key works without re-auth inside the window.

Uncertainty and OEM Variance

Marked for review: OEM implementations differ on exactly which events trigger invalidation (lock-screen removal only versus any biometric change), so test on the target device fleet. The step-up recommendation holds regardless, but the frequency of user-facing prompts will vary.

One diagnostic detail changes the server-side recommendation: whether the refresh token is single-use and rotating. If it is, a stale token presented after invalidation can be rejected outright rather than merely flagged, which is stronger than a step-up prompt.