This is a concrete authorization-sensitive consequence of #6144 rather than a separate root cause. #6144 tracks that WFE2's in-memory account cache is not invalidated after account updates. The additional concern here is that cached account state is used while authenticating account-keyed JWS requests, so stale state can affect authorization decisions and not only response freshness.

Today WFE2 can be configured with an account cache that wraps the existing StorageAuthorityReadOnlyClient. Account-authenticated request validation reads the account record through that cache, checks that the account is still valid, extracts the stored JWK, and then verifies the JWS. If the cached record is stale, the WFE can make that authentication decision with old account state.

Two concrete cases fall out of that behavior:

• After account deactivation, a WFE with the pre-deactivation account record cached can continue to authenticate requests as a valid account until the cache entry expires.
• After key rollover, a WFE with the pre-rollover account record cached can continue to authenticate requests signed by the old key until the cache entry expires.

The practical impact is bounded by the cache lifetime and deployment assumptions, and this does not require giving WFE2 direct read access to the primary database. The WFE already has a read-only SA client. The issue is specifically the extra WFE-local cache layer being used for authorization-sensitive request authentication.

Expected behavior: requests that can mutate account, authorization, challenge, order, revocation, or issuance state should authenticate against the existing read-only SA client rather than the WFE-local account cache. Cache-backed account lookups can remain for explicitly read-only/POST-as-GET paths where stale data is acceptable.

Proposed patch shape:

• Keep the WFE-local account cache.
• Add an account-authentication helper that bypasses only the WFE-local cache by calling the existing StorageAuthorityReadOnlyClient directly.
• Use that helper for account update/deactivation, key rollover, new order, finalize order, authorization/challenge mutation, and subscriber-key revocation.
• Keep cache-backed validation for explicitly read-only POST-as-GET helper paths.
• Purge this WFE's local cached account entry after successful account update/deactivation and key rollover as defense-in-depth. The security boundary is still the fresh read-only SA lookup on mutation/issuance paths.