What working across major government departments taught us about Privileged Access.
For security and risk leaders who’ve noticed the humans keep finding ways around a bloody good plan.
There’s a myth about Privileged Access Management that refuses to die. It goes something like this:
“Buy a tool.
It’s for the techies.
Switch it on.
Job done.”
Anyone who’s ever run a transformation programme knows it’s nonsense.
PAM isn’t a tooling exercise.
PAM is a people exercise wearing a technical badge to get past the front desk.
Nowhere was this clearer than in large government departments.
This wasn’t a crisis project. No breach. No headlines. Just organisations with real-world complexity: layers of access built up over years of change, new joiners layered on top of legacy structures, permissions that made sense once upon a time but had quietly outlived that context.
It was familiar. And because it was familiar, it was risky.
What we found when
we peeled back the wallpaper.
Picture this: a room of senior teams in government departments reviewing a list of privileged accounts that had survived like digital fossils. Old roles created for long-closed projects. Accounts nobody could confidently explain. Access was given “temporarily”, which somehow became permanent. A few surprises, one or two mysteries.
Everything worked for them. But those same accounts might have worked for outsiders, too, and they would not have known.
Then we asked a question nobody had yet considered: what does “privilege” really mean here?
The big tech-admin accounts are obvious. But what about the people who can create and approve suppliers in finance systems, or those who can post as the organisation on social media? The risk if these accounts were compromised is real, yet less visible. Privilege is not just technical. It is power, and the gaps are rarely obvious.
That difference between visible access and hidden influence is where risk lives.
How we discovered
where risk lives.
Seeing the risk was one thing. Understanding it was another. We didn’t want to assume the gaps we had uncovered were purely technical, so we ran a discovery process.
It started with workshops and interviews. We helped people map out who could do what in every system and why. We shadowed workflows, traced approval paths, and followed the proverbial paper trail through various departments, including infrastructure, networks, engineering, HR and communications. What seemed like a simple list of accounts quickly became a map of influence, responsibility, and informal authority.
The biggest insight for the client wasn’t about technology at all. The systems mostly worked. The challenge was human. Understanding who needed access, why they needed it, and how they used it revealed far more friction than any tool ever could.
This set the stage for the next phase: figuring out how to design controls and governance that people would actually use rather than resist.
The tricky part
wasn’t the tech.
Early on, someone said, “I don’t mind losing access. I mind not knowing why.” That line summarised the emotional reality of PAM better than any maturity model.
Because privileged access is psychological.
It touches on competence, trust, autonomy, and, if we’re being honest, ego.
It asks people to give something up with no obvious reward.
The equation is simple:
When people don’t understand the change, they resist it.
When they don’t trust it, they bypass it.
So we didn’t begin with architecture diagrams or vendor comparisons.
We began with people.
How we approached it
with the Rainmaker way.
We took the organisation back to first principles:
“Let’s look at everyone who can change something important.”
A simple question.
A revealing exercise.
Once the map was visible, we built from there in a sequence that kept the programme stable:
1. People as the starting point — conversations before controls
2. Governance design — consistent decisions, not heroic exceptions
3. Technical design — if a process made sense, people actually used it
4. Delivery last — phased, calm, and deliberately un-dramatic
It sounds basic. It isn’t.
Most organisations try to do this backwards.
The honest bits, the
challenges that always show up.
There were predictable hurdles:
Legacy roles that no one wanted to touch “just in case”
Senior stakeholders who assumed seniority meant privileged access, but never used it.
Teams were convinced controls would slow them down
Systems so customised they may as well have been folklore
Documentation that described an organisation that no longer existed
And then there were the subtler, human moments:
A team is nervous about losing autonomy
An individual convinced that a new access route meant they were being “checked up on”
Someone quietly admitting they’d held admin privileges for years purely because “it was easier”
Some felt PAM didn’t trust them. In reality, it focuses trust on the person, not the account, in case it’s not actually the right person using it.
This is the stuff that never appears in procurement documents. But it’s the stuff that determines whether PAM succeeds or fails.
What actually changed,
beyond the obvious security uplift.
Yes, departments gained:
Clearer governance
Reduced privilege sprawl
Stronger access controls
A roadmap aligned to actual risk
Better visibility of “who can do what, where and why”
But the bigger shift was cultural.
People understood the “why”.
Approvals became less emotional.
Shadow processes reduced.
Teams trusted that controls weren’t there to make life harder; they were there to make risk visible.
Transformation isn’t about grand launches.
It’s about everyday behaviour shifting in small, permanent ways. And that happened.
Lessons for change managers.
The ones you won’t find in glossy whitepapers
Start with ownership. If you don’t know who owns systems, owns the data in systems, owns risk, owns accounts, then everything downstream is theatre.
Treat your documentation as potentially a work of fiction until proven otherwise.
Find out what people think they’ll lose — not access, identity.
Governance must work under pressure, not just in workshops.
If there are lots of exceptions, something upstream isn’t aligned.
Teach first. Enforce second.
And remember: privilege is political. Expect heat. Plan for it.
If you’re at the start
of your own PAM journey.
Start with these questions:
How do your people and teams think about access today, and how might they respond to proposed changes?
How would you like them to think about access in the future — what mental model are you aiming for?
What are the important keys, who actually needs them, and who just thinks they do?
How many privileged accounts exist simply because it was easier to leave them in place?
What would break if legacy access disappeared tomorrow?
And most importantly, does your organisation understand its own risk story?
If the answer is “not fully”, you don’t need a product yet. You need clarity. Clarity is what gives you the power to build something secure, sustainable, and genuinely transformative. For those curious to see how their organisation measures up, there’s a simple PAM maturity assessment available.
Oh yeah, and thanks for reading
You may also like these.
