Every infrastructure post-mortem contains the same paragraph, and it is never the one anyone expected to write. The initial access was not sophisticated. It was a credential that existed, that worked, and that nobody had a reason to look at — because it had been legitimately issued months earlier, for a reason that had since ended.
That is standing access. It is not a vulnerability, so no scan finds it. It is not a misconfiguration, so no posture report flags it. It is the residue of a hundred reasonable decisions: a key added for a migration, a database password shared during an outage, a kubeconfig sent to a contractor who did good work and left on good terms.
It stays invisible to the risk register because a risk register asks what could go wrong, and standing access is the record of things that already went right.
The distribution problem
The mechanism is worth being precise about, because it explains why the usual fixes only partly work.
Infrastructure access is almost always handed out rather than granted. A key is copied to a host. A kubeconfig is copied to a laptop. A password is copied into a password manager and then, at two in the morning, into a chat window.
Once a credential has been copied, the organisation has permanently lost the ability to list its copies. There is no query that returns the answer. Revocation stops being an operation and becomes an investigation — carried out by people, at the exact moment the person who knew where everything was has left.
This is why the honest test of an offboarding process is not "did we remove their access". It is: can we show a third party, at any point in the future, that access ended when we say it ended? Most organisations that pass the first test fail the second, and usually find out during an audit or a due-diligence review, which are the two worst moments to find out.
Why the obvious fixes fall short
Configuration management as the source of truth is a real improvement. It makes access declarative and puts it in version control, which gives you a change record. But it covers only the hosts under management, does nothing for database or cluster credentials, and tells you what state you pushed rather than what state existed during a session.
A bastion host gives you one door and one place to audit. That is genuine perimeter control, and for many organisations it is enough. What it does not give you is any knowledge of what happened after the door: no per-command record, no way to reduce someone's privileges while they are working, and credentials still have to be handed out behind it.
Short-lived certificates are the strongest thing an engineering team can build for itself. Expiry does the revocation work automatically, which removes the human step that fails. The cost is that you are now running a certificate authority whose private key is the most sensitive object your company owns, and you are changing the SSH configuration of every production host to trust it — so the security project needs a production change window before it delivers anything.
The property that matters
Strip away the implementations and the useful property is one sentence: access should be granted per session, scoped to a task, with an expiry enforced by a system rather than remembered by a person.
Everything follows from that. If the credential never reaches the laptop, there are no copies to enumerate. If the grant expires by itself, offboarding cannot be forgotten. If every session is recorded, "prove it" is a query rather than an interview.
The industry calls this category privileged access management, and it has historically been sold as a seven-figure programme with a twelve-month rollout — which is exactly why most engineering organisations under a thousand people have a bastion and a spreadsheet instead. The requirement was never in dispute. The delivery vehicle was.
A note on pricing
There is an oddity in how access tooling is usually sold that deserves more attention from budget owners than it gets.
Much of the market prices per protected resource — per server, per host, per node. Think about what that means. The bill grows every time you add a machine. An autoscaling group that doubles overnight doubles a line item. A team that splits a monolith into twelve services on twelve instances has just paid twelve times more for the same twelve engineers doing the same work.
The tool is billing you for the size of your infrastructure. But what it actually controls is how many people can reach it, and that number moves slowly and predictably. It is a headcount number, and you already forecast headcount.
Per-seat pricing tracks the variable that reflects the real risk surface and the real value delivered. It also turns the budget conversation into a forecast rather than a negotiation, which matters more than it sounds, because tooling that gets expensive at scale is tooling that quietly gets routed around at scale. And a security control people route around is worse than no control, because it also produces a false sense of coverage.
What to be clear about
None of this removes the need for judgement. A broker that holds credentials is a high-value target and has to be run like one — hardened, backed up, and ideally penetration-tested before go-live. Putting a system in the access path means accepting it as a dependency of that path. And no tool produces compliance. Tools produce evidence, and evidence is what an auditor asks for.
What is achievable, and what most organisations do not currently have, is a state where "who can reach production right now" is a query with a correct answer, and "prove that access ended in May" is a timestamp rather than a story.
That is a lower bar than the market usually sells against. It is also the bar that post-mortems keep showing we have not cleared.
Tessera is a self-hosted access broker for SSH, Kubernetes, databases and RDP — priced per seat, deployed inside your own network, free to self-host for a single administrator. How it works →
LinkedIn version
~310 words. Link in the first comment, not in the post. Publish from a founder's personal profile as well as the company page.
Every infrastructure post-mortem contains the same paragraph, and it is never the one anyone expected to write.
The initial access was not sophisticated. It was a credential that existed, that worked, and that nobody had a reason to look at — because it had been legitimately issued months earlier, for a reason that had since ended.
That is standing access. It never appears on a risk register, because a risk register asks what could go wrong, and standing access is the residue of a hundred things that went right. A key added for a migration. A database password shared during an outage at 2am. A kubeconfig sent to a contractor who did good work and left on good terms.
The mechanism is simple, and it explains why the usual fixes underperform: infrastructure access gets handed out, not granted. Once a credential has been copied, you have permanently lost the ability to list its copies. There is no query that returns the answer.
So the honest test of your offboarding process is not "did we remove their access".
It is: can you prove it, to someone who is not you, six months from now?
Most organisations that pass the first test fail the second — and usually find out during an audit or a due-diligence review, which are the two worst possible moments.
The property that fixes it is one sentence: access granted per session, scoped to a task, with an expiry enforced by a system rather than remembered by a person.
That has historically been sold as a seven-figure programme with a twelve-month rollout, which is exactly why most engineering orgs under a thousand people have a bastion host and a spreadsheet instead. The requirement was never in dispute. The delivery vehicle was.
I would be curious what people here have actually had to produce as evidence in an audit. Not what the policy said — what the auditor accepted.
(first comment, same account)
Longer version, including why per-server pricing bills you for the wrong variable: [link]
Top comments (0)