The Challenge
Governance of AWS Identity Center (also known as AWS SSO) access across a 160+ account government environment at Geoscience Australia had, over roughly seven years, fragmented into 21 separate, disconnected tools - each one built to solve a single narrow slice of the problem: granting access, revoking it, listing who belonged to what, notifying an owner. None of them shared a design, an owner, or a way of working with the others.
None of this was a crisis in any single moment. But it left the organisation exposed in a way that only becomes obvious when someone asks a simple question: who has access to this account, and why?
What I Found
A review of the full estate confirmed the sprawl wasn't the result of one bad decision - it was the accumulation of many reasonable ones. Each tool solved a real problem in isolation, but none of them shared a data model, an approval workflow, or an owner, so nothing about the system as a whole was resilient, auditable or reportable. By the time I reviewed it, several tools had fallen out of use entirely, and most hadn't been touched in years.
On accountability: access decisions had no dependable, current link to the person actually responsible for the account, so approvals - where they existed at all - had no real authority behind them.
On visibility: there was no way for an owner to simply ask "who currently has access to my account?" without chasing someone down. That gap mattered more than any individual tool's shortcomings, because it meant revocation always lagged behind grant - access accumulated, and nothing forced it back down.
How I Approached It
I designed and built a single, AWS-native platform to replace the entire fragmented estate outright, rather than patching or extending what already existed.
Before requesting an access or a report on anything, staff sign in with a one-time link, sent to their government email - so every request is tied to a real, verified person, even when it's submitted on a colleague's behalf. From there it's self-service: requests route straight to the account's real owner for a decision by email, with revocation held to that same standard. Because that owner record is what the whole model relies on, it's protected by a guardrail at the organisation level, so nobody inside a member account can edit it and appoint themselves the approver.
Reporting is equally self-service - any account owner can request, at any time, a full picture of who holds access to their account - rolled out deliberately, account by account, rather than switched on across the whole estate at once.
What Changed
Twenty-one disconnected tools with no shared audit trail and no accountable approval path became one governed platform, with its own ownership data protected from tampering by a guardrail at the organisation level. Access requests that used to depend on finding whichever legacy tool still worked are now resolved in hours, tied to a real, signed-in person rather than a typed email address. Approval authority sits with each account's real, current owner instead of a static list nobody remembered to update. And for the first time, any owner of an account brought into the platform can see exactly who has access to it, on demand.
These weren't just technical improvements. They translated into materially lower risk of stale or orphaned access sitting on sensitive accounts, an audit posture that can produce evidence on demand rather than being reconstructed after the fact, and meaningfully less ongoing administrative BAU load on the platform support team.
Lessons for Enterprise Cloud Platform Management
Sprawl is a symptom, not a starting point. Twenty-one tools didn't come from one bad decision - they came from twenty-one reasonable ones, each solving an immediate problem in isolation. When a domain keeps generating one-off tooling, step back and ask what the single system of record should have been from the start.
Automation is only as trustworthy as the identity and data behind it. Auto-approval and owner routing both depend on knowing who a request really came from and who genuinely owns the account - so both need protecting: verified sign-in for the requester, and an organisation-level guardrail stopping anyone from editing their own account's ownership record.
Route accountability to the people who actually hold it. Tying approval to an account's real owners keeps decisions with the people who understand its risk, and keeps the platform team the system's custodian rather than its bottleneck.
Visibility is what makes governance self-sustaining. A grant process without an equally easy way to see current access always drifts toward over-provisioning. Making reporting self-service - not something someone has to ask for - is what lets revocation keep pace with grant.