Disclosure: I work on Tessera, which is on the buy side of this. I have tried to cost the build side properly, because a comparison where the build option looks stupid is a comparison nobody believes.
Every engineering team that has this problem considers building it. That instinct is correct. SSH certificates are a well-understood, well-documented mechanism, everything you need ships with OpenSSH, and the first working version takes a competent engineer about a week.
The week is not the cost. Here is what is.
The build, honestly
The CA itself. You generate a key pair, configure targets with TrustedUserCAKeys, and sign user keys with a short validity. This part genuinely is a week, and it works.
Protecting the CA key. This is where the estimate starts moving. The CA private key can now grant access to every host in the fleet. On a laptop it is an incident waiting to happen. So you want it in an HSM or a KMS, which means an integration, which means the signing operation now has an availability dependency, which means a runbook for what happens when that dependency is down. Call it two to four weeks including the operational work.
Issuance. Someone has to request a certificate and something has to decide whether to give them one. That means integrating with your identity provider, mapping groups to principals, building a request path, and building an approval path if you want anything time-boxed or justified. This is the real project, and it is measured in months rather than weeks, because it is where the requirements keep arriving.
Rollout across the estate. Editing sshd_config on every production host. Technically trivial, organisationally not: change window, sign-off, rollback plan, and the discovery that four hosts are not in configuration management and one of them is important.
Audit. Certificates tell you a session was authorised. They do not tell you what happened in it. If your requirement includes per-command history or session replay — and if you have auditors, it does — that is a separate system, and it is a much harder one than the CA.
Kubernetes and databases. None of the above covers them. Cluster access and database credentials are separate problems with separate solutions, and in most organisations they are where the genuinely dangerous access lives.
Ongoing. OpenSSH releases, key rotation, principal changes when the org restructures, the on-call rotation for a system that is now in the path of every production login, and the knowledge concentration risk when the one person who understands it takes another job.
The number
The first version is a week. A production-grade system covering SSH only, with IdP integration and an approval flow, is a quarter of engineering time. Adding session audit roughly doubles it. Covering Kubernetes and databases as well is a small internal product with a permanent maintenance cost.
Say two to three engineer-quarters to reach parity with a commercial tool on SSH alone, plus ongoing maintenance somewhere between a tenth and a quarter of an engineer indefinitely.
At a loaded cost of $150–200k per engineer-year, that is $75k–150k to build and $15k–50k a year to keep. Adjust for your market, but the shape holds.
When building is right anyway
I want to be clear that this is often the correct decision.
- You are large enough that per-seat pricing exceeds the build cost. At a few thousand engineers the arithmetic inverts, which is why the very large companies all built their own.
- Your requirements are genuinely unusual. Air-gapped, exotic hardware, a regulator with specific opinions, an existing identity system nothing integrates with.
- You need to read the source. For some organisations this is not a preference.
- The work is strategic. If access is close to your product, owning it is reasonable.
If two or more of those are true, build. The rest of this is not aimed at you.
When buying is right
The argument for buying is not that building is hard. It is that the build has a specific failure mode: it gets to 80% and stops.
The CA gets built. The issuance flow gets built. Then the engineer who owned it moves to a different team, the approval workflow stays manual, the audit piece never happens, Kubernetes never gets covered, and two years later you have a system that works, that nobody fully understands, and that does not answer the question the auditor is actually asking.
That is not a hypothetical failure mode. It is the normal one, because internal tools are funded by attention rather than by budget, and attention moves.
The second argument is scope. Buying covers SSH, Kubernetes, databases and Windows on day one. Building covers SSH first and the rest maybe, and the rest is where the interesting damage lives.
The pricing variable, which is worth checking
If you do buy, look at what the vendor charges for.
A lot of this market prices per protected resource — per server, per host, per node. Think about what that does. 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 pays twelve times more for the same twelve engineers doing the same work.
You are being billed for the size of your infrastructure. What the tool controls is how many people can reach it, and that is a headcount number you already forecast.
This matters beyond the invoice. Tooling that gets expensive at scale is tooling that quietly gets routed around at scale — a shared account here, a bastion exception there — and a control people route around is worse than no control, because it also produces a false sense of coverage. Per-seat pricing is not just cheaper for most organisations; it removes the incentive to undermine the thing you bought.
The actual decision
Not "can we build this" — you can. It is: will this still be maintained in three years, and will it cover Kubernetes and databases by then?
If yes, build it. If you are not confident, the honest comparison is not build cost versus licence cost. It is a licence against a system that reaches 80% and stalls, which is a worse outcome than either.
Tessera is a self-hosted access broker for SSH, Kubernetes, databases and RDP, priced per seat, free to self-host for a single administrator. https://tessera.company/docs/get-started/what-is-tessera/
Top comments (0)