A settlement signing key never left its device, yet your clearing partner accepted instructions nobody authorised — where do you look?

## What custody settled, and what it left open Hardware-backed custody buys exactly one property: the private half cannot be copied out. Everything else about this incident is untouched by it. A signature the partner accepted verifies against your public half, which means it was produced by that key, which means the device produced it — because nothing else can. So the useful conclusion is not "who has the key" but **"who could make the device work."** One caveat before you lean on that. The claim holds if the key was *generated* inside the device. If it was generated elsewhere and imported, an off-device copy may exist and the whole line of reasoning reopens. Check the provenance — ideally an attestation from generation time — before you rule it out rather than after. ## Scope it from the operation record first A device that performs operations counts them, and most will tell you how many signatures a given key produced over a window. Put that number beside the number of settlement instructions your own systems raised in the same window: - **Counts match** — the extra instructions did not come from this key, and you are looking at the partner's acceptance rules, not your custody. - **Device count is higher** — you have the size of the exposure in operations, which is a bounded, countable number. That is the practical dividend of custody: an exported key gives you an unbounded problem, an invoked key gives you a counted one. The record tells you *how many*. It does not by itself tell you *who* — identity comes from the credential presented on each call, which is the next thread. ## The three ways an invocation gets made 1. **The credential the service authenticates with.** Where does it live, how is it delivered, who else can read the host or the process, and is it shared across environments? A credential copied out of a deployment artefact buys someone signatures without ever touching the key. 2. **The device's own access rule.** Which identities may invoke *which* key for *which* operation. The common real defect is a rule written once, broadly, so that every service and every operator identity on the estate can invoke the settlement key because narrowing it later was never done. 3. **The submission path.** The device signs a digest. It cannot tell an authorised settlement instruction from an attacker's. An internal endpoint with no authorisation of its own, a queue anyone can publish to, or an operations tool that signs whatever it is handed turns the device into a signing service for whoever reaches that path. In practice this is where these incidents most often live, because it requires no credential theft at all. ## The fast control is invocation, not the key | Action | Effect | Cost | |---|---|---| | Revoke the credential the caller authenticates with | Stops that caller immediately | Anything legitimately using it stops too | | Disable the key at the device | Stops all signing with it at once | Your own settlement flow stops | | Narrow the device's access rule | Stops identities that never needed it | Needs to be right first time under pressure | | Generate a new key in the device | New signatures use a new key | Slow: every verifier must accept the new public half, and the old one keeps verifying until they stop | Note the direction on the last row. **Generating a new key is replacement, not withdrawal.** The partner goes on accepting the old public half until they are told to stop, and nothing about a new key undoes instructions already accepted. Withdrawal is an action against the party that verifies, and with an external partner it runs on their lead time, not yours. ## What would have caught this, and what would not Alerting on **failed** authentication to the device would have caught nothing: these calls succeeded. The signals that fit are the ones that notice legitimate-looking work that nobody needed — the device's operation count diverging from settlement volume, invocations from an identity that has no business signing, or signing outside the hours the batch runs. Reconciliation with the partner is the outermost of these and usually the one that actually fires. ## The order you work in Stop further invocation, then repair the submission path, then decide about the key. Re-keying is the slowest control you have here and the least useful in the first hour: it does not stop the caller, does not withdraw the old public half, and does not touch what the partner already accepted.