Prevention eventually fails, and the design decisions that matter are the ones determining how much an attacker gets when it does. A way of thinking about architecture that starts from the assumption of compromise rather than treating it as the failure case.
The assumption that changes the design
Prevention is the intuitive layer, and it is where most effort goes: keep them out, patch quickly, authenticate properly. All of it worth doing, and none of it holds indefinitely.
The change that matters is not adding more of that. It is asking a different question at design time — assume the attacker is already inside this component, and ask what they can reach from here.
That question produces different architecture rather than more controls. Controls are things you add. Reach is a property of how the thing was arranged, and arranging it well is mostly free once you are doing it deliberately.
Blast radius as the primary metric
How much is reachable from any single compromised component.
It is a better primary metric than a count of controls, for a structural reason: controls are binary and eventually fail, whereas radius is continuous and can be permanently reduced. A control you added is a control that can be misconfigured tomorrow. A door that does not exist cannot be left unlocked.
One credential that exports the entire user table and one that reads a single non-sensitive queue are the same item on a checklist and nothing alike in an incident.
The decisions that actually shrink it
Hold less. Data never collected cannot be taken, and this is the only measure with no failure mode.
Keep the most sensitive material in a form the system cannot read. If the application never holds the key, a full compromise of the application yields ciphertext.
Separate credentials by purpose, so one stolen key opens one door. This is least privilege stated in terms of consequence rather than policy.
Write down what each component can reach. Not for an auditor — for yourself. The exercise is uncomfortable in a useful way, because the answer is usually broader than the mental model of it, and the gap is where the surprises live.
Expire by default. A credential with no expiry is a permanent one, and permanence is the property that turns a small old mistake into a current incident.
Designing the aftermath
The part that is usually missing entirely, and every item is a design decision made long before anything goes wrong.
Can you tell that it happened? Can you tell what was reached, specifically, rather than inferring a range? Can you revoke one thing without taking the service down, which determines whether revocation actually happens quickly? And can you tell affected people something precise instead of issuing the paragraph everybody recognises as meaning we do not know?
The last one is not public relations. The ability to say exactly what was exposed is a property of the system, decided during design and not available for purchase afterwards.
The cost, stated honestly
This is harder, and the costs are features rather than effort.
No server-side search over material the server cannot read. No recovery for a user who loses their key — support will carry that forever. No convenient administrative view of user data, which means some support problems become genuinely unsolvable.
Pretending these costs are small is why teams adopt this approach and then quietly abandon it: the friction arrives later than the decision, usually during a deadline, and the retreat is made one exception at a time.
Choosing this means choosing those losses deliberately, in advance, rather than discovering them and reversing.
Where it is not worth it
Material that is not sensitive does not need it and should not pay for it.
Small systems where the added complexity becomes its own risk — key management introduces failure modes, and a team that cannot operate it reliably has traded a clear risk for a confusing one.
And cases where losing recovery genuinely harms users more than the exposure it prevents. For plenty of consumer software that is the honest answer, and saying so is better engineering than applying a pattern because it sounds rigorous.
The question I ask of my own designs
If somebody held every credential this component has for a month before anyone noticed, what would they have, and what could I tell the people affected?
If I cannot answer both halves specifically, the design is not finished. The second half is the one that gets skipped, and it is the half the people affected will actually experience.