Our story
We built this because we missed it
For years we ran a third-party system like this one for several hundred people. It made audits easy, it made incidents shorter, and it meant nobody — including us — walked around production with the power to break it. Then we re-platformed, and it could not come with us.
TemprBac is a rebuild of a third-party system we relied on for years — the same idea, without the boundary that made us lose it. What follows is what that system did, the scheme we ran on it, and the one thing it could not do.
What it was like to have it
We showed it to clients. Not as a slide about our security posture — as a screen: here is every person who can reach this environment, here is how long they can reach it for, and here is the record of every time anyone did. It was the easiest part of every audit conversation we had, because the evidence was a query rather than a project.
The place it paid for itself most often was incidents. Something breaks, and the first twenty minutes of a bad incident are usually spent establishing what changed. With this in place, "who could even have changed this, and when" was answerable immediately, for every system, by anyone on the call. That deleted a whole genre of Slack thread — the one where eleven people are asked whether they touched something, and the useful answer arrives after the outage is over.
It was also, quietly, the thing that stopped us hurting ourselves. Not attackers: ourselves. An engineer with permanent administrative rights on a platform will eventually run the right command against the wrong resource, and the only reliable defense is not having the rights at the moment the mistake is available to make.
The shape of the scheme
Everyone on the team — several hundred people — was in one base group. That group granted nothing on the far end. It held no roles in any application; it was purely the answer to "is this person allowed to request anything at all". Joining the company put you in it. Leaving took you out of it, which is a single revocation with a very large blast radius, in the good direction.
Then, deliberately, everyone could see every package. Support engineers saw the same catalog as administrators. Hiding the catalog would have bought nothing — requesting is not holding, and every request was gated anyway — and it would have cost the thing that made the system work: people could see what existed, so they asked for the right thing instead of asking a human what to ask for.
The environments were then split along the same three tiers that most applications already model internally, which is not a coincidence and is covered below.
| Tier | What it granted | How it was approved | Share of the work |
|---|---|---|---|
| Support | Reads. Look at logs, configuration, queues, dashboards, state. No writes at all. | Auto-approved. Request it, hold it, it expires. | ~90% |
| Operator | All reads, plus the writes the role legitimately needs. | One teammate's approval. | ~10% |
| Admin | The rest, including things with no undo. | A ticket and a manager's approval. The highest packages required several approvals. | Rare |
Production access required a ticket. That was not a bureaucratic reflex — it meant the reason for the access was recorded next to the access, so the audit answer was never just who, it was who, and what they said they were doing.
The number that changed how we think about this
What emerged from working with the people who actually used it was the finding we did not expect. By sitting with internal users and modeling what their job really needed, about 90% of their daily work fitted inside an auto-approved, read-only support package. No writes. No approval step. No waiting on anybody. They asked for it, they got it in seconds, and it went away on its own.
They could elevate to operator when they needed to change something, with a teammate's approval — and they did that roughly 10% of the time. Which means that for 90% of the working day, the people running the platform were structurally incapable of damaging it. Not trusted not to. Not trained not to. Unable to.
Most of the safety did not come from the approvals. It came from discovering how much of the job never needed a write in the first place, and making that the default path with nothing in its way.
That is also why the friction argument never really landed against us. The 90% case got faster, not slower: no ticket, no waiting for a human, no "can someone add me to this group". The approval cost was concentrated in the 10% of actions where a second pair of eyes is worth something, which is where everybody agrees it belongs.
Why it spread
We did not have to sell it internally. Teams asked to be added, and then asked to integrate their own workflows into it — pipelines requesting their own scoped, short-lived access instead of running as a permanent service identity with permanent rights. It was safer and it was more transparent, and critically it was simple enough to not be in anyone's way: grabbing a package for the thing you were already looking at took seconds, so people did it rather than routing around it.
It worked across the whole platform, the on-premises Active Directory included. That breadth was the reason it could be the single answer to "how do I get access to X" rather than one more tool for one more system.
The one thing it could not do
Then we re-platformed, and the system could not follow. It was somebody else's product, built inside one platform's boundary, and that boundary was exactly where our new infrastructure started. We could not extend it, because it was not ours to extend, and every replacement we evaluated had the same shape: each governs its own platform well and stops at the edge of it. That is a fine description of a feature and a poor description of a strategy, because no real organization's access lives in one platform.
We missed it badly enough to build our own — and to build it the only way that survives a re-platforming: on the primitive every system already shares. Groups and roles are how Entra ID, Okta, Google Workspace, GitHub, AWS IAM and on-premises Active Directory all express access, and every one of them exposes that over an API. Govern the group membership and you govern the access, whoever owns the platform underneath. We wrote up that argument in full in the platform wall every PIM hits.
If the product we were paying for had worked across other clouds and on-premises, the way TemprBac does, we would not be here. That sentence is the whole product strategy.
What we bring to it
Years of running this practice at scale, on a product that was good enough to build a whole operating culture around and limited enough to lose. We know which parts people actually use, which parts sound essential and never get touched, and which failure modes only show up in the second year. That is what is built into this, and it is why the read-only tier — the unglamorous part — is the one we treat as the product's center of gravity.
It is priced so that finding out is not a procurement decision. We explain that in why it costs this little.
Everyone's environment is a little different, and everyone's scheme ends up a little different too — ours was three tiers because that is what our applications already modeled. The tiering is yours to choose. What travels is the primitive underneath it, and that is the same everywhere we have looked.