Identity programs rarely fail because of the platform. They fail because teams build roles around legal entities instead of job functions. They add segregation of duties after the roles exist, and their access reviews record who has access without removing any of it.
The software arrives last and automates whatever came before it. I watched enterprises repeat these mistakes, often with a new platform each time.
I write here so the people who answer for identity outcomes can see the failure before they pay for it twice.
IT is people first
Information Technology is pretty simple. It’s a collection of people who use policies, processes, and systems (in that order) to achieve outcomes desirable for an organization.
The order is the point. No system without a process, and no process without a policy.
In practice, a named person decides who should have access before anyone writes the rule. The rule fits in one sentence before anyone designs the workflow. The workflow has an owner and a deadline before anyone signs a platform contract. When a program reverses that order, unanswered questions pile up on the platform.
I learned the order by watching it break
My career runs through Lockheed Martin, Lucent Technologies, PwC, BNY, and corporate information security at General Mills. I served twice as a Director of IT and answered for the outcome as well as the design.
In 2005, I led a discovery test team at Lockheed Martin and studied SAML and OAuth. Those protocols now sit under every cloud identity platform. The testing taught me that federation moves a trust decision from one system to another. It never makes the decision for you.
One access review I watched looked clean. Accounts payable staff could release payments but couldn’t create vendors. Procurement staff could create vendors but couldn’t release payments.
Then an employee who covered both teams created a vendor and paid its first invoice. No second person ever touched the transaction.
When I traced the cause, I found that each team had reviewed only its own application’s roles. Both teams approved the right access for their own system, and nobody asked what those permissions let one person do across both.
The fix treated vendor creation and payment release as one segregation of duties conflict, wherever each action happened. Anyone who needed both for coverage got temporary access that expired, and every payment they released needed an independent approval first.
Two sensible roles can add up to one person who controls the whole transaction.
Every quarter, one manager received hundreds of access review items with names like AP_PROC_L3 and FIN_SYS_EXT. The deadline was clear. What those entitlements allowed was not, so approving everything became routine.
When I looked closer, I found an employee who still held administrator access from a project that ended a year earlier. The manager had approved it in four straight reviews without knowing what it meant.
The fix rewrote each entitlement in plain language: Can create vendors, Can release payments, Can add users or change their permissions.
Once the manager could read the administrator entitlement, the decision was easy: the employee’s current job didn’t need it. The team removed the access instead of recording it for another review.
A manager can’t remove access they can’t read.
Four layers and six Guides
Every post sits in one of four categories: People, Policies, Processes, and Systems. Each category names the layer where that post’s fix lives. The six Guides are the long references I keep updated as the posts beneath them go live.
Start with IT Is People Using Policies, Processes and Systems for the thesis. Then read How to Run an IAM Program That Survives Year Two for sequencing, ownership, and funding.
Role design lives in RBAC Works When Roles Are Job Functions and Segregation of Duties Starts in Role Design, Not the Audit. The process Guides are User Access Reviews Should Remove Access, Not Just Record It and Fix the Identity Lifecycle Before You Buy the Platform.
Credentials
- CISSP
- 21 years in identity and access management
- Director of IT, twice
- Lockheed Martin, Lucent Technologies, PwC, BNY, General Mills (corporate information security)
Outside the work
I grew up in Orlando and live in Sanford, Florida. When I’m not working on identity programs, I photograph people and the places I travel.
For interviews, speaking, or to discuss an identity program, email me or connect with me on LinkedIn.