The deal closes. The integration plan goes into motion. IT gets a ticket to merge the Okta tenants, sync the directories, and make everything work. By the time someone actually looks at what the combined identity environment contains, it's been ninety days. Sometimes longer.
What they find — what I find, every time I get called in — is the same list. Five gaps that survived every checklist, every standup, every "are we good on security?" conversation. Not because anyone was careless. Because these gaps are invisible until you know exactly where to look.
This is where to look.
"These aren't edge cases. They're the default state of every post-acquisition identity environment I've worked in."
Orphaned accounts from the acquired entity
Every acquisition brings headcount that was already in motion before the deal closed. People who were terminated in the final weeks, contractors whose engagements ended, roles that were eliminated as part of the integration plan. Their accounts don't automatically disappear. They go quiet.
In a merged Okta environment, quiet accounts are invisible accounts. They don't generate help desk tickets. They don't fail logins — because nobody is trying to log in. They sit active, with provisioned access to downstream applications, waiting. An auditor who pulls a user population report will find them. So will an attacker who compromises the right set of credentials.
The number is always higher than the acquiring team expects. I've seen environments where terminated employees from the acquired entity were still active in Okta and fully provisioned to SaaS applications six months after close. The system never got the signal to deprovision them because the offboarding process lived in the acquired company's HR system, which nobody had integrated yet.
The fix isn't complicated. It's a reconciliation — map every active account in the merged tenant against a current, authoritative headcount list and deprovision everything that doesn't match. The hard part isn't the technical execution. It's getting agreement on which HR system is authoritative when two companies suddenly share one identity environment.
Admin privilege sprawl across merged Okta tenants
Before the acquisition, each company had its own Okta admins. Super admins, org admins, read-only admins, help desk roles — a structure that made sense for the size and needs of each individual organization. When the tenants merge, both sets of admin accounts come with them.
Nobody goes back and asks whether all of them still need to be admins. The answer, almost universally, is no. Combined environments routinely carry three to four times the necessary administrative access with no documented justification. Former admins from the acquired entity who have since moved into non-technical roles. Service accounts created for integrations that no longer exist. Shared admin credentials from before the acquiring company had proper PAM tooling.
Admin sprawl is the gap auditors charge the most for. It's also the one that's hardest to justify during a cyber insurance renewal. When an underwriter asks "how many users have admin access to your identity provider?" and the answer is a number that surprises everyone in the room, that's a finding that becomes a condition.
Start with a full export of every admin role in the merged tenant. Map each account to a named individual and a current business justification. Everything without a justification gets downgraded. The review takes a day. The remediation takes a sprint. The audit finding it prevents would have taken months.
No documented JML process for the combined workforce
Joiner-mover-leaver. Every identity governance program has one. The problem post-acquisition is that there are now two — and neither was designed to handle the other's edge cases.
I worked through a scenario where a SaaS application's access request workflow had to be rebuilt from scratch after an integration because the business wanted approvals routed through a specific individual. The IAM standard required approvals to go through a governance group with at least two members. The governance group existed — but it had one member. Nobody had caught it because the process had been working fine at the acquired company, where informal approval chains were normal and auditable enough.
Tribal knowledge does not survive an acquisition. The person who knew that certain contractors should be provisioned differently, that the legacy ERP integration needs a manual step, that access to the finance applications requires a secondary approval from the CFO's office — that person is either gone, overwhelmed, or no longer in the right seat to be the institutional memory. What was an informal process becomes an undocumented gap the moment it's expected to scale to the combined headcount.
Document the merged JML process before the first new joiner goes through it after close. Define which HR system triggers which identity events. Define who approves what, in which system, with what fallback when the primary approver is unavailable. Write it down while you still have people from both sides in the room who know how things actually worked.
Access certifications not run post-close
An access certification is a formal review: every user, every application, every access right confirmed or revoked by the appropriate owner on a defined schedule. Most mature organizations run them quarterly or annually. Post-acquisition, the schedule breaks.
The merged entity has never reviewed the full combined user population. The certification that ran last quarter only covered one company's users. The one before that covered the other's. Nobody has ever looked at the complete picture — both populations, all applications, including the newly integrated ones — and asked a business owner to confirm that every access grant still makes sense.
Every unreviewed access grant in the combined environment is a finding waiting to be written. If an auditor or pen tester asks to see access certification records that cover the merged entity and there aren't any, that's a material gap. In a PE-backed environment heading toward an exit or an audit, it's the kind of gap that shows up in due diligence and creates leverage for a valuation haircut.
Run a certification on the merged population before the 90-day mark. It doesn't need to be perfect — it needs to establish a baseline. A documented, timestamped review that says "we looked at every account in the combined environment, we confirmed or revoked access, and here is the record" is worth more than a sophisticated certification program scheduled for next quarter.
Cyber insurance answers do not match actual IAM state
At renewal, the acquiring company answered the underwriter's IAM questions accurately. MFA coverage, admin account controls, access review cadence — all of it reflected the pre-acquisition state of the identity environment. Then the acquisition closed and the environment changed.
The policy didn't change with it.
Underwriters ask specific questions. How many users have privileged access? What percentage of users have MFA enforced? When was your last access certification completed? The answers that were true in January are not true in the environment that exists in April, after the Okta tenants merged and the combined headcount doubled and nobody ran an access cert on the new population.
An insurance claim against a policy whose answers no longer match the actual environment is a claim that can be denied. This is not a hypothetical. Underwriters have increasingly sophisticated questionnaires and increasingly sophisticated counsel. A post-acquisition environment that has drifted from its disclosed IAM posture is an exposure that doesn't appear on any technical audit — until it needs to.
Map the current IAM state of the merged environment against the answers on the last renewal. Find the gaps. Fix the ones you can before the next renewal. Disclose the ones you can't. An underwriter who discovers a material change at claim time is a different conversation than one who was kept informed throughout the policy period.
These five gaps don't appear because integration teams are negligent. They appear because identity governance is treated as an IT task in a process that's being managed as a business transaction. The people making the timeline decisions are not the people who know what "merge the Okta tenants" actually involves.
The 90-day window matters because that's when the environment is fluid enough to fix these things without a major remediation project. After 90 days, the bad state becomes the baseline. People build on top of it. Processes form around it. By the time an auditor finds it, what was a configuration problem has become a program problem.
The best time to look for these gaps is before close. The second best time is right now.
Know what's in your environment before an auditor does
The gaps above are findable. None of them require a six-month engagement or a new platform. They require someone who knows exactly where to look and has done it before in environments like yours.
Risk Ready Identity conducts focused IAM assessments for PE-backed companies — purpose-built to surface these gaps in two weeks, prioritize what matters before your next audit or renewal, and hand you a remediation plan your team can actually execute. No ambiguity about scope, no open-ended hourly billing.
The next one goes deeper.
First-hand observations from inside post-acquisition IAM environments. No pitch. No filler. Straight to your inbox when it publishes.
Subscribe — it's free