Which keys across a payments estate earn custody in a device that will not export them?
answer
- a tier, not a default
- how fast can you re-key
- operations per second against the ceiling
- a synchronous dependency at peak
- name what the untiered keys get instead
basics
~20 sKeys you cannot re-key quickly because outside parties verify them, with low operation rates and high per-misuse consequence. High-rate data-path keys and keys you can replace in an afternoon do not earn the cost, the latency or the extra failure domain.
solid answer
~50 sThe deciding question is how expensive a compromise would be to recover from, not how sensitive the key feels. A settlement signing key verified by an external partner who takes days to accept a replacement is the strong case: low operation rate, severe per-misuse consequence, and a re-key you do not control. A key on a high-volume data path is the weak case — the device's sustained rate becomes a ceiling, every operation adds a round trip, and the key can usually be replaced internally in hours. I would publish a tier, not a mandate: this class goes in a device, that class stays in software with a short life and tight scope. A blanket "everything in hardware" rule produces software copies kept quietly for the failover path, which is worse than either option chosen honestly.
go deeper
Recall that keeping a key in a device that will not export it has costs — speed, capacity, money — so it is applied to some keys rather than all of them.
Explain the two criteria that decide most cases: how fast the key can be replaced with everyone who verifies it, and whether the device's operation rate can carry the workload.
Work a real case with numbers: peak rate against the device's sustained rate, recovery target against the verifier's lead time, and the second device the availability stake implies.
Own the standard itself — the tier, the named alternative for everything outside it, who may add a key, who pays, and the evidence you produce when an audit asks which keys can leave a device.
## The question is which keys, not whether Hardware-backed custody buys one property — the material cannot be copied out — at a price in latency, throughput, availability and money. Treated as a universal good it becomes a mandate nobody can meet; treated as a tier it is one of the few controls that genuinely changes what an incident costs. The job of a lead here is to write the tier and defend where the line sits. ## Six criteria, in the order they usually decide it 1. **How fast can you re-key?** This dominates everything else. If the verifiers are external parties you cannot compel, a replacement public half moves at their change process — days or weeks. A compromise you cannot recover from quickly is worth spending on preventing. 2. **What does one misuse cost?** One accepted settlement instruction is a payment. One decrypted record is a record. Consequence per operation, not volume, drives this criterion. 3. **What is the operation rate?** Suppose a device sustains around 1,000 signing operations per second and peak settlement runs at 200 per second — comfortable, with headroom for a retry storm. A data path at 50,000 operations per second is not a candidate at any price: the device becomes the system's throughput ceiling. 4. **What availability are you staking?** The device becomes a synchronous dependency of whatever it signs for. Budget for a second device in a different failure domain, or accept that the signing path is exactly as available as one box. 5. **What does it cost per key, per year?** Devices, spares, provisioning, firmware maintenance and the people who hold custodian components. This is the criterion teams under-count, because the box is the cheapest part. 6. **Is misuse externally detectable?** Where a counterparty reconciles what you sent, misuse surfaces on its own and custody plus an invocation record gives you a bounded scope. Where nothing reconciles, custody without monitoring buys less than it looks like it does. ## A worked tiering, with the numbers stated Assume an estate with an external clearing partner (five working days to accept a new public half), internal service-to-service signing (re-key in under an hour, entirely under your control), and a bulk data path at tens of thousands of operations per second. | Key class | Re-key lead time | Rate | Decision | |---|---|---|---| | Settlement signing, verified externally | ~5 days | ~200/s | Device custody, with a second accepted key in a second device | | Internal service-to-service signing | < 1 hour | ~2,000/s | Software key, short life, narrow scope, automated replacement | | Bulk data-path keys | minutes | ~50,000/s | Not a candidate; the device would be the ceiling | The line is drawn by criteria 1 and 3, and it moves when either changes. If the partner ever agrees to hold two accepted public halves and swap them on your word, the settlement key's re-key time collapses and the case for custody weakens — which is worth knowing, because that conversation is cheaper than a second device. ## What a blanket mandate actually produces Declare that every key lives in a device and three things happen. Teams with rates the device cannot serve either miss their throughput targets or route around the rule. Teams facing a device outage keep a software copy "for the failover path," so the material exists in software *and* the estate believes it does not — the worst of both. And the genuinely important keys get no more attention than the trivial ones, because everything is tier one. A standard holds when it names the tier **and** the acceptable alternative: what a key outside the tier must do instead — a short life, a narrow invocation scope, automated replacement, and an owner. Without the second half, the standard is aspirational and the exceptions are undocumented. ## What you should be able to answer about the standard - Which key classes are in the tier, and the criterion that put each one there. - What the estate does when a device is unreachable — fail closed, or fail over to a second accepted key. - Who can add a key to the tier, and who pays for the device. - What an external audit is told when it asks which keys can leave a device and who can prove it: an attestation captured at generation, not a screenshot of a setting. That last one is the difference between a policy and a control. The tier is only real if, for every key in it, you can produce evidence of where the key was born.
- Why does re-key lead time dominate the decision more than sensitivity does?Because sensitivity tells you how bad a compromise is, while lead time tells you how long you are stuck with it. A highly sensitive key you can replace in an hour has a bounded incident; a moderately sensitive one whose replacement waits on an external party's change process does not. Prevention is worth most where recovery is slowest.
- A team asks for device custody for a key signing 40,000 times a second. What do you say?That the device would become the throughput ceiling and the request is really about blast radius, which has cheaper answers at that rate: a short-lived key, a narrow invocation scope, automated replacement and an owner. Then check whether the high-rate key can be split from a low-rate key that genuinely does earn the tier.
- What is the most common hidden cost when an estate adopts this broadly?The people and the process, not the hardware — provisioning, spares, firmware maintenance, custodian components and rehearsals. Second is availability: each device is a synchronous dependency, so a serious deployment is at least two in different failure domains, which roughly doubles the visible cost before any of the human cost is counted.
saying these in an interview costs you the question
- Put every key in a device; hardware custody is strictly better
- The cost of the tier is the price of the boxes
- Hardware custody removes the need to plan re-keying at all
- Throughput is never a constraint because signing operations are fast
- Adding the device cannot reduce availability, since it only signs
- A key is tier one because it feels sensitive, not because recovery is slow