the key that must refuse to start

A second factor is only as strong as the secret behind it. If the material that protects every enrolled user's authenticator state lives in configuration with a fallback, the control has a quiet ceiling, and the ceiling is whatever the fallback is.

The design kept enrolments' shared secrets in the database as ciphertext only, with the nonce travelling alongside, and took the encryption key from the platform secret store at startup. The decision worth recording is what happens when that key is missing or malformed: the process refuses to start and says so. It does not generate one, does not derive one from something else, and does not continue with a warning. A server that cannot protect the factor does not serve.

The same idea repeats at smaller scale inside the flow. A completed password check does not hand a session to a privileged role that has not enrolled; it hands over a one-time enrollment token instead. A step-up challenge carries its own expiry, a small attempt budget and single-use semantics, so a challenge is something spent rather than something that stays valid.

One thing was deliberately left out: recovery codes. Losing a device becomes an administrative reset rather than a self-service bypass. That is a support cost accepted on purpose and written into the record.

What it proves: the team treats a missing key as a reason to stop, and will take an operational cost over a credential path that exists for convenience.