Lessons from simplifying identity environments in large federal and commercial organizations.
At the SOFWERX OSBP event, a representative from a prime contractor asked me a simple question. What does Zephon do differently from every other ICAM integrator?
I answered with examples. Lots of them. Somewhere in the middle, I noticed I was getting passionate. Then I realized something uncomfortable. We had been doing this work for years, and I had never said it plainly.
So on the flight home, I wrote what I found:
Identity environments don't break. They accumulate.
Nobody designs a messy ICAM program. It gets that way one reasonable decision at a time.
A sync tool to bridge two directories. A script to cover a gap the platform didn't. A custom screen inside the vendor product, because the deadline was Friday. Each one made sense at the time.
Ten years later, you have a platform people work around instead of rely on. Provisioning fails quietly. The helpdesk absorbs the difference. Patches get postponed because nobody knows what they'll break.
The usual response is to add something. Another tool. Another layer. Another team. Sometimes that's the right call. Often it just makes the pile taller.
Here's what we did instead, on real engagements.
1. Retire what's already redundant
A Defense agency brought us in to help upgrade an identity governance (IGA) platform built over 10 to 12 years. It carried a lot of technical debt.
One of the first things we noticed: Microsoft Identity Manager (MIM) was syncing two Active Directory domains. The enterprise IGA platform was already provisioning both of them. MIM was doing a job that was already done. We helped the agency retire it.
The same agency used Oracle Access Manager (OAM) and Oracle Unified Directory (OUD) to control access to its governance applications. That meant proprietary header-based authentication and web agents in the middle. Meanwhile, the agency already ran Okta as its enterprise identity provider. We're now helping retire OAM and OUD and move those applications to standards like SAML and OIDC. That work is still underway.
The payoff: a smaller infrastructure footprint, lower licensing costs, and fewer things to patch.
Before you buy something new, check what you're already paying for.
2. Put logic where it belongs
Same agency. Custom code inside the database ran scheduled batch jobs and called external systems. But the IGA platform already had a scheduler, and it already talked to those systems. So we moved the jobs there. The database administrators went back to administering databases.
A custom application talked directly to the IGA database. We put it behind a REST API wrapper that uses the IGA's own API instead. My rule is simple: nothing but the IGA application should touch its database.
Custom screens had been built inside the vendor product. Every vendor patch put them at risk. We moved them out into separate applications, so upgrades no longer break custom functionality.
We also replaced an aging Oracle ADF interface with Spring Boot, Thymeleaf, and JavaScript. It's a smaller stack, and it's far easier to hire engineers for. That matters to whoever supports this system after us.
Together, these changes made something possible that wasn't before: a proper DevSecOps pipeline for the application.
3. Simplify the rules people have to live with
A federal civilian agency had more than 20 rule combinations for provisioning Active Directory accounts. Each was based on user type, department, organization, status, and more.
We were migrating that logic to a new system. Porting the mess as-is would have been easy. Instead, we distilled it into five rules. Rules people could read. Rules support staff could actually troubleshoot.
The same agency had no easy way to see when birthright provisioning failed. We moved provisioning onto AWS SQS queues and put a dashboard on top. Now everyone involved can see where a user is in the flow. Switching from synchronous to asynchronous processing helped performance too.
4. Get heavy work off the platform that matters
That agency's users were running enormous reports, against terabytes of data, inside the enterprise IGA tool. It bogged the platform down and pulled it away from its real job: identity management and governance.
We recommended pointing the agency's existing reporting solution, already hosted in the same AWS GovCloud tenant, at a read-only replica of the database. Most users only ran reports. They didn't build them. So the added licensing cost was minimal.
I've written before about why you should externalize your SailPoint reporting. This was that advice, applied.
5. Stop patching what should be retired
A higher education client assigned Microsoft 365 licenses with a PowerShell script. It was more than five years old. It ran on a local Windows server, failed at random, timed out, and couldn't resume gracefully. The result was helpdesk tickets and manual fixes.
We were asked to update the script for new license mappings. We recommended something else. The client's identity governance solution already had all the user data needed to pick the right license, and it was already provisioning to Active Directory. So we moved the logic there, using dynamic groups to assign licenses. The process became near real-time and idempotent: run it twice, and you get the same right answer.
The script was retired. Patching it one more time would have been easier. That's how a script gets to be five years old.
The Pattern
Looking back across these engagements, we do three things every time.
- Diagnose. Find what's actually causing failure, not just the symptom that generated the ticket.
- Simplify. Remove, consolidate, or relocate what doesn't belong. Add only what improves reliability, visibility, or maintainability.
- Modernize. Rebuild what remains on standards and supported patterns, so the customer can run it without permanent dependence on us.
Notice that we added things too: queues, a dashboard, an API layer, new applications. Simplification isn't about deleting. It's about making every component earn its place.
How do you know an identity program is struggling? Watch for three signs. Manual workarounds to grant or remove access. Helpdesk tickets that exist only because something upstream failed. Access granted outside the program's visibility. If those keep showing up, the program isn't working yet, no matter how good the architecture diagram looks.
Why we work this way
When my team looks at a client's environment, I ask one question: how would we build this if it were our own system?
We'd want fewer moving parts. We'd want logic in the platform designed to own it. We'd want to patch without holding our breath. And we'd want a system we could hand to the next team without a six-month apology.
I wrote about simplification, consolidation, and automation as principles back in 2024. This is what those principles look like in real identity environments.
If your ICAM environment is harder to run than it should be, it's fixable. You can see more examples of what simpler looks like, or reach out and tell us where your program is stuck.