Access status, application ownership, permissions, groups, and activity were difficult to inspect together.
Back to projects
Case study 02 / Identity & access governance platform
Passport makes access decisions visible and reviewable.
An access-governance workspace for applications, permissions, groups, users, recurring access certifications, and audit history across 15 role types.
Overview
One operating model for access that had previously been reviewed in pieces.
People responsible for user access, application ownership, and recurring review decisions.
Information architecture, end-to-end workflows, interaction patterns, and the interface system.
A shipped workspace that connected access setup, evidence, review states, and decision history.
Challenge
Reviewers needed context, not another list of users.
A user could belong to multiple applications and groups, carry different permissions, and change ownership over time. Looking only at current access left the reviewer without the evidence needed to understand why it existed.
I organized the product around the decision itself. The central tradeoff was speed versus accountability: repeated review work had to move quickly, but bulk actions could not flatten ownership gaps, non-expiring credentials, or unresolved access changes.
System model
Access becomes reviewable when every layer keeps its ownership and evidence.
-
Resource
Application
The system being accessed and the people responsible for it.
-
Capability
Permission
The action a person or group is allowed to perform.
-
Assignment
Group
A reusable bundle of entitlements: permissions and special abilities.
-
Identity
User
Status, office, applications, groups, and access conditions.
-
Decision
Review record
Requester, activity evidence, reviewer action, and preserved history.
The same model supported daily administration and periodic governance, so the review layer did not become a disconnected reporting tool.
Start with the evidence behind unresolved access.
The pending state places requester, applications, linked groups, and recent log events inside each review row. Approve, edit, and remove actions stay beside the evidence, so reviewers do not have to reconstruct context across screens.
User flow
A review can move forward only when every access decision is resolved.
-
Queue
Enter through exceptions or a scheduled review
Work starts in an ongoing exception queue or a periodic review, prioritized by what needs attention.
-
Evidence
Understand why the access exists
Requester, ownership, applications, groups, activity, and audit history sit in a single view.
-
Decision
Keep, change, or escalate the access
Every user gets one of three outcomes: confirm access, edit or remove it, or request missing context.
-
Resolution gate
Separate ready work from unresolved work
Ready marks the user reviewed and unlocks completion; unresolved work stays visible in the queue.
-
Submit
Close the cycle with an auditable record
The review submits only when required decisions are complete, preserving reviewer action and history.
-
Exception path
Unresolved access returns to the queue
Context travels with it, so the next reviewer starts from evidence instead of reconstructing it.
Review stage
Resolution gate
Gate passed
Unresolved return
End state
The completion gate protects accountability without slowing every decision: standard access can move quickly through keep or change, while exceptions remain visible until someone owns the next action.
Unresolved work never disappears into a pending state — it returns to the queue with its context preserved, so the next reviewer starts from evidence instead of reconstructing it across screens.
Completion changes the state without erasing the evidence.
Moving a user to Reviewed closes the operational task, while the expanded log remains available for follow-up and audit. The result is a review record that explains both the decision and the path that produced it.
Access foundation
The review works because the underlying access model stays inspectable.
01 / Applications
Make ownership visible at the resource level.
Each application keeps developers, managers, approvers, related groups, notes, and the source URL in one expandable record.
02 / Permissions
Keep capability definitions tied to their application.
The split view lets administrators scan applications and inspect permission names, expiry policies, and record history without losing context.
03 / Groups
Scan reusable access bundles before editing them.
Groups stay organized by application, with permissions, special groups, status, and history visible in the same comparison surface.
04 / Scoped edit
Move from a table signal to a controlled change.
The user drawer keeps identity, application choices, groups, role, and special abilities visible while the broader user list stays in context.
Key design decisions
Dense governance work needed clarity without losing control.
Keep the reason for access close to the decision.
Requester, ownership, activity, and audit events stay in the same working context as restore, edit, and review actions, so access is judged against actual use — the practical basis of least privilege.
Show the actions each reviewer can actually take.
Applications, groups, and special abilities remain explicit so a reviewer can understand the consequence of a change before applying it.
Separate pending, reviewed, recurring, and submitted work.
Distinct states prevent an unfinished review from looking complete and keep follow-up work visible across cycles.
Let repeated decisions move quickly without hiding exceptions.
Standard access can be processed efficiently, while unusual credentials, ownership gaps, and unresolved changes remain explicit reasons to stop.
Observed impact
From legacy-engineering dependency to a governed access product owned by the business.
The meaningful change was not a measured speed benchmark, but the move from developer-managed access operations to a visible, repeatable product workflow.
Legacy developers managed permissions, assigned users to access groups, and handled changes directly. There was no dedicated third-party or internal product for structured access governance.
Applications, users, groups, roles, activity, ownership, exceptions, and review decisions became part of one inspectable identity-governance model.
Routine access work could move from a legacy-development queue into direct action by authorized teams, turning long handoffs into minutes for standard cases.
Decisions became traceable through ownership, activity, affected resources, and audit history, while unusual permissions remained explicit reasons to review or escalate.
Why in-house mattered
A company-owned access platform moved governance out of legacy engineering workflows and closer to the people, policies, and systems it served.
Access records, review decisions, ownership, and audit history could live in a company-controlled permission model instead of remaining embedded in legacy developer-managed processes.
The product could support the company's 15 role types, application ownership, recurring reviews, and exception paths without forcing internal policy into a generic vendor model.
When an access flow failed or a policy changed, the internal product and engineering team could investigate the affected model and ship a focused response without joining a vendor queue.
Applications, users, groups, activity, ownership, and decisions formed one first-party evidence layer that could support deeper audits and improve future access-review rules.
Operational impact
A clearer governance layer for access decisions across 15 role types.
Connected applications, permissions, groups, users, ownership, and audit evidence in one access model.
Moved ongoing exceptions and recurring user reviews into a shared workflow with distinct pending and reviewed states.
Made access changes easier to inspect by keeping the requester, activity history, and affected resources visible around the decision.
A structured RBAC model of roles and permissions supported different access responsibilities without reducing them to a single generic administrator.
Immediate exceptions and scheduled certification cycles could be handled in the same workspace while remaining visibly separate.
Reviewers could trace who changed access, what changed, and which application or group was affected before completing the review.