A great deal has been written about Zero Trust, and almost all of it is about principles. It is far more useful to see what those principles turn into under real operation: which decisions get made, what has to be given up, and what breaks when the model is applied only halfway.
Below is how the infrastructure my team works in is actually built. It is not a showroom: a client receives the same scheme, because defending someone else’s perimeter by rules you do not apply to yourself is dishonest.
Servers: we separate accounts, not just machines
The default deployment target is Hetzner, but that is not the important part. Proxy servers, primary servers and backup servers live on separate accounts with separate payment methods.
This risk is usually overlooked. Redundancy gets built at the level of machines and data centres, while the provider account quietly remains a single point of failure: a disputed payment, an anti-fraud false positive, an abuse complaint, and the entire infrastructure including its backups becomes unavailable at once. Separate accounts with separate payment instruments remove that specific scenario rather than some abstract notion of resilience.
There is no lock-in to a platform. We work with clouds (AWS, Google Cloud, Microsoft Azure), with any bare-metal provider, and with virtualisation on VMware ESXi, Proxmox VE or QEMU/KVM. What that looks like on a concrete cluster is covered in my write-up on Proxmox as code. Choosing a platform is a question of the task and the jurisdiction, not of habit.
Secrets: OpenBao and a hardware module
Secrets live in OpenBao, and the master keys live in a YubiHSM 2 hardware module. The difference between “passwords in an encrypted file” and “the key physically never leaves the device” is fundamental: in the second case, compromising a server does not compromise the keys.
Then comes the rule that makes Zero Trust operational rather than declarative: every secret is issued temporarily and rotated once the task is done. There is no engineer holding permanent access just in case. Stolen credentials stay useful only until the end of the task they were issued for.
Engineer workstations
- Hardware keys for everyone. A YubiKey is a condition of access, not a recommendation for the willing. Phishing stops working as a class of attack, because an intercepted password is useless without the physical key.
- Encrypted MacBook or Linux only. Windows is not used on workstations. That is a deliberate narrowing of the attack surface, not an argument about taste.
- Apache Guacamole for reaching administrative interfaces: the session runs through a gateway rather than straight from an engineer’s laptop, and it stays in the logs.
Nobody touches data by hand
Zero Trust means no one has direct access to data. Every change goes through an Ansible pipeline, and only after a backup has been taken.
That buys three things at once. The change is reproducible: it can be read, reviewed and repeated. It is reversible, because the backup was taken beforehand rather than “probably yesterday”. And it does not depend on the state of one particular person on one particular evening, since the most common cause of production incidents is not an attacker but a tired administrator holding root.
Where Zero Trust breaks in practice
The model almost never collapses all at once. It collapses one exception at a time, and every exception looks reasonable at the moment it is granted.
- “Give me permanent access, I am tired of requesting it.” One such account cancels the entire point of temporary secrets: an attacker only has to find that one.
- A secret pasted into a chat. It is instantly outside the vault, outside rotation and outside the logs, and it lives there for years.
- Backups on the same account. A classic: redundancy exists, but it dies together with the primary perimeter from a single administrative action by the provider.
- An exception “just for this one server”. Roughly six months after the first one, the infrastructure consists of exceptions.
So Zero Trust is a discipline before it is a set of products. You cannot buy it. You can buy a secret store and hardware keys, but if a permanent convenience account lives next to them, your security is defined by that account and not by the rest of the scheme.
What we deliberately do not do
We do not run first-line support. Not because it is beneath us, but because it is a different profession with different economics and a different rhythm. Our area is expertise and core infrastructure: design, security, and running the critical perimeter.
The same honesty applies to our own tooling: some of it we do not sell as a boxed product. Until something has enough mileage on our own workload, selling it means handing the experiment to the client.
Frequently Asked Questions
Why separate provider accounts? An account is as much a single point of failure as one rack: a block makes the whole infrastructure unavailable together with its backups.
Why a hardware module rather than an encrypted store? The master key never leaves the device, so a compromised server does not mean compromised keys.
Why changes only through a pipeline? They are reproducible, reversible, and independent of how one person feels on a Friday evening.
Does Zero Trust require new infrastructure? No. It describes how access is granted, not what hardware you own, and maps onto clouds, bare metal and virtualisation alike.
Need a Consultation?
If you are building a protected perimeter and want to know where its single points of failure still are, book a free 15-minute call. We will go through your scheme and show you the weak spots.
