Our story
We built this because we believe in it
For years we've run this system, this scheme and 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. It was a simple way to manage the system, securely and at scale. We want to share this with the world. Every business, every team should have the ability to plug in temporary access. To keep things simple. To keep things secure.
TemprBac allows you to reduce the number of roles you assign people, standing permission those roles grant, down to zero — or at least to the minimum set of logically manageble sets. Ideally fewer than 5. This is not a new idea, this is our story of running this and how it changed the way we think about access.
What it's like having TemprBac
We show it to clients. Not as a slide about our security posture — as a demo: 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 is the easiest part of every audit conversation we have, because the evidence is a query rather than a project. Everyone gets the same permission, even the admins. We can fire up a screen showing no access, walk through how to get access (under 1 minute) and then show that it expires automatically.
The place it pays for unexpectedly 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. Basically things anyone should be able to do and see. | Auto-approved. Request it, hold it, it expires. Fast. | ~80% |
| Operator | All support, plus the power user stuff you really want to guard | One manager or lead approval. Ticket expected. Measures in minutes. | ~15% |
| Admin | The rest, including things with no undo and ownership. Break Glass. | A ticket and a manager's approval. The highest packages required several approvals. | ~5% |
Production access requires a ticket. That is not a bureaucratic reflex — it means the reason for the access is 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 80% of their daily work fit inside an auto-approved, support package. No dangerous actions allowed, just normal day-to-day stuff. No approval step. No waiting on anybody. They ask for it, they get it in seconds, and it goes away on its own. Removing the friction here allows for less resistance during adoption. And when you don't need to be in the target system, why allow your user access to it at all?
They could elevate to operator when they needed to change something, with a teammate's approval — and they did that roughly 15% of the time. Which means there is an easy 85% reduction of blast radius for 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 elevated role 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 80% 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 20% 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 works across the whole platform, the on-premises Active Directory included. All our cloud providers, all of our on-premise data centers. That breadth is the reason it can be the single answer to "how do I get access to X" rather than one more tool for one more system. the platform wall every PIM hits.