Vvanakor
Back to writing
Data Security2 min read

Zero trust fails on friction, not architecture

Zero TrustData SecurityArchitectureEncryption

The diagram is not the hard part

Everyone can draw it. Identity at the centre, no implicit trust from network position, verification on every request, policy enforced close to the resource.

I have never seen a zero trust programme fail because the architecture was wrong. I have seen several fail because verification became expensive enough that people built a way around it.

Friction is the actual threat model

Make authorisation slow and teams will cache credentials. Make it bureaucratic and they will request permissions far broader than they need, because asking twice is worse than asking once for too much. Make it unreliable and someone will add a bypass for emergencies that quietly becomes the normal path.

Now you have a zero trust diagram and a shadow network. The diagram is still accurate. It just no longer describes how work gets done.

So the metric that matters is not coverage. It is how long a legitimate request takes to be authorised, measured at the P95, and whether that number is going down.

At the data layer

Perimeter thinking dies slowly, and it dies last around data. The instinct is still to protect the store rather than the record.

Classify first, because you cannot write policy about data you have not described. Then push enforcement to the data plane — the query path, not the network in front of it. A database reachable only from a trusted subnet is still a database that returns everything to whoever reaches it.

Encryption in transit and at rest is table stakes and proves almost nothing about authorisation. It protects against the wrong threat for this conversation.

Non-human identities

Most access to your data is not human. Service accounts, workload identities, pipeline runners, API principals. They usually outnumber the humans, they rarely have owners, and their credentials rotate on a schedule measured in years.

If your zero trust programme only covers people, it covers the minority of your access.

The order I would do it in

Identity inventory, including the non-human ones. Data classification. Policy at the data plane. Then measure the cost of compliance for a legitimate request, and keep driving it down.

The last step is the one that gets cut, and it is the one that determines whether any of the others survive.

Back to writing