Locking every door but one — and why the break-glass has to be yours

Almost every operations team weighing a zero-trust access layer in front of running infrastructure asks the same question, and it's a fair one: if we lock everything down to one door of yours, and that door dies, are we locked out of our own machines? This isn't an idle worry. It's the real reason many teams never tighten as far as they should, leaving SSH wide open "just in case" — paying for a security layer and then hand-propping open the exact door it was meant to close.

The blunt answer: yes, you can lock down so that every network path in runs only through the mesh — SSH closed, RDP closed, every static-IP port closed. And yes, if that's the only way in and it dies, you're locked out. So the real question isn't "can you lock it down" — it's where the break-glass lives, and who owns it. This is exactly where the whole guarantee can quietly come apart, because "break-glass" means two completely different things, and one of them is the thing you were paying to remove.

"Break-glass" has two readings. One is provider-side break-glass: the provider keeps some way back into your machine when their access layer fails. The other is break-glass you own: the machine is still reachable, but only through a management plane that sits inside your own infrastructure, never through the provider. These sound similar on a feature list. They are opposites in the threat model.

A provider-side break-glass is a backdoor wearing a friendly label, and this is just logic. If the provider can get back into your machine after the network layer is fully locked, then the provider has a way in that doesn't pass through your policy — precisely the capability that "data never traverses provider infrastructure, the provider can't decrypt" is supposed to remove. You cannot have both "the provider can never touch my machine" and "the provider can get me back in when their layer dies." If both are on the same page, one of them is false. A provider-side escape hatch is not an extra feature bolted onto a sovereign design; it is the deletion of what made it sovereign.

The honest answer keeps the break-glass on your side of the line — and it's feasible because two different planes are involved. "Lock everything to the mesh" only speaks to the in-band plane — the network layer, the thing the access layer actually governs. The break-glass lives on a different plane entirely — out-of-band: your cloud provider's serial console, IPMI/BMC, the hypervisor console. This plane doesn't traverse the host's network stack; it reaches beneath the OS. So it isn't "another open network port" — it's a separate management plane, and most important, it sits inside your cloud account or hardware, outside the access provider's reach. The honest claim is narrow and exact: Ankayma is the only in-band way in; recovery runs over an out-of-band plane that lies outside Ankayma's trust boundary.

The consequence is three things a centralized, trust-the-cloud model can't say:

• You choose the lockdown level; you aren't forced. Run the access layer alongside your existing SSH and leave it untouched; or tighten node type by node type; or go fully mesh-only — it's a dial you set to your own risk appetite, not a switch someone flips for you.
• Mesh-only lockdown becomes viable in production, because the lockout risk is retired by an out-of-band path you own — not by a provider-side button.
• The access provider dying or being locked out doesn't trap you, and the provider has no secret recovery path. The way back belongs to your infrastructure, so trust doesn't quietly migrate to the vendor. That's the sentence a trust-the-cloud model can't say, because there the recovery path usually is the vendor's infrastructure.

Don't skip the cost — this model isn't free, it's different.

• The out-of-band path has to be real, and you have to rehearse it. A break-glass you've never tested is a break-glass you don't have. Provisioning console access, verifying it works with the network locked, drilling it periodically — none of this can be outsourced to the access provider, because outsourcing it to them is how you recreate the backdoor.
• The break-glass trust root shifts to your infrastructure provider's console IAM / BMC, not to a cryptographic boundary. This is a bounded, disclosed trust delegation — you must own and audit it, not pretend it isn't there.
• The failure semantics are a genuine judgment call, not a default. When the access layer dies: does the lockdown ruleset hold (safe, but you must use out-of-band to get back in) or tear itself down (you get in, but the posture failed open)? For banks and regulated workloads: stay-locked by default, out-of-band mandatory. For lighter workloads: you may choose otherwise. Which threshold you pick is yours.

And the limit I'll state plainly: an out-of-band path protects you against lockout and against a provider with a backdoor. It doesn't make you immune to the fact that your cloud provider is also a party you trust at that layer, and it doesn't remove the need for discipline — time-box it, alert on it, write every use into the audit ledger. The trust doesn't vanish; it moves — from the access provider to a plane you own and can audit. That move is the point.

Let me state my bias. I build toward break-glass-that-belongs-to-the-customer, so be skeptical of how I frame the trade-off. But the claim is narrow: don't let the fear of lockout talk you into a provider-side escape hatch that quietly reintroduces the exact backdoor you were trying to remove. The right fix for a single door is not a provider-side way back in — it's a way back in that lives inside your own infrastructure.

So what should you actually ask? Run the question forward. If your agent died right now on a fully locked-down machine, what's my way back in — and is it your infrastructure or mine? If it's the provider's, ask the follow-up that matters: what else does that same path let the provider do, on a normal day, without me? The answer to the second question is the real measure of how sovereign the design was in the first place.

I write about this because the break-glass conversation is where a lot of "zero-trust" promises quietly fail, and it's a core part of what I'm building at ankayma. If you're weighing how to lock infrastructure down as far as it should go without locking yourself out, I'd like to hear your constraints — including the ones that make my approach look wrong.

Luffy Bao is CTO at Ankayma, building zero-trust mesh infrastructure for regulated organizations in Southeast Asia and the Gulf. Questions or counterarguments? hello@ankayma.com