an identity service that keeps no record

Everything else trusts the identity service, which makes it the worst place to be uncertain. An audit found two kinds of uncertainty. The service was not recording sign-in events or administrative events, so the question of who changed what had no answer from the system itself. And the documented recovery route, a break-glass administrative account whose credential lives in the store, no longer matched what the service accepted. The recovery path was a belief rather than a path.

The repair ran offline against the administrative account, then synchronised the credential back into the store and proved it by authenticating with it. Event recording and administrative event recording were switched on. Lockout on repeated authentication failures was enabled, deliberately non-permanent so a locked account returns to usable on its own.

Before any of it, the realm configuration was exported and the database dumped, because identity changes are the hardest kind to reverse and the least forgiving to rehearse badly. Verification was behavioural rather than declarative: sign in to the console, complete a single sign-on round trip through the applications that rely on it, then fail authentication deliberately until the account locks and confirm it unlocks again.

The cost is honest. Lockout is a denial-of-service primitive installed on purpose, and what makes it safe is the non-permanent setting plus a test that shows the account coming back, while what makes it defensible is that the record of the lockout now exists. What it proves is that for the service everything trusts, the audit trail and the recovery path are features with tests, not paragraphs with confidence.