When should organisations re-evaluate their identity architecture after platform convergence?

When convergence changes the trust model, not just the login page

Platform convergence becomes a reason to re-evaluate identity architecture when it merges identity classes that used to be governed differently. The important question is not whether one product can centralise access, but whether it can preserve distinct trust boundaries, lifecycle rules, and approval paths without turning policy differences into hidden exceptions. That is where architectural assumptions usually break first.

In practical terms, the trigger is a change in control semantics. If workforce access, privileged access, partner access, and machine access now flow through one platform, the architecture must prove it can still distinguish ownership, assurance, delegation, and revocation logic. A single console does not automatically mean a single security model.

Convergence also creates a useful forcing function to revisit whether the current design reflects the real operating model. If governance, provisioning, review, and deprovisioning decisions are still fragmented behind the scenes, the organisation may have achieved tool consolidation without achieving identity convergence. The architecture should only be considered stable when policy, evidence, and enforcement line up across the full identity lifecycle. NHIMG’s Identity Convergence Guide is a good reference point for distinguishing true convergence from simple platform aggregation.

Where the hidden control gaps usually appear

Converged platforms most often fail at the seams between identity types. The same access review cadence may work for employees, but not for service accounts with automated dependencies or certificates that expire on operational timelines. When one platform spans all of them, the architecture has to prevent the strongest control model from being incorrectly applied to the weakest population. NHIMG’s NHI Lifecycle Management Guide helps frame those lifecycle differences clearly.

Another common gap is centralised reporting with decentralised enforcement. Teams may see a single inventory, yet each identity type still relies on separate approval logic, separate remediation paths, and separate ownership. That arrangement can look mature on paper while still leaving orphaned accounts, stale credentials, and overbroad entitlements in place. In that case, convergence has improved visibility more than it has improved control.

Re-evaluation is also warranted when the platform changes what “good” governance means. For example, if the new platform can issue access faster but cannot express different expiry, attestation, or segregation rules by identity class, the organisation has traded precision for convenience. NHIMG’s IGA Buyer's Guide is useful where the key question is whether governance depth survived the consolidation.

What to test before declaring the architecture fit for convergence

Before accepting the converged model, test the architecture against the hardest identity population, not the easiest one. The platform should demonstrate that it can handle different trust assumptions, ownership models, and revocation speeds without using manual exceptions as the real control. If a class of identities can only be governed through custom scripts, ad hoc approvals, or downstream cleanup, the design is not yet aligned.

It is also worth checking whether the platform changes the organisation’s ability to see identity sprawl. Convergence should improve discovery, policy consistency, and review quality, but only if the underlying inventory is accurate and the control model is explicit. NHIMG’s Identity Visibility and Intelligence Platforms (IVIP) Guide is relevant when the issue is whether visibility is strong enough to support governance decisions.

Where certificates, service identities, or workload credentials are part of the converged estate, re-evaluation should include how those assets are created, rotated, and retired. A platform that cannot express lifecycle discipline for machine-facing identities often pushes risk into vaulting, exception handling, or separate tooling. NHIMG’s Certificate Lifecycle Management Buyer's Guide is a useful checkpoint when convergence touches machine identity and expiry-heavy controls.

Practitioner Guidance

What to prioritise: Reassess architecture first when convergence changes the trust boundary between identity populations, then decide whether the platform can enforce different lifecycle and approval rules without relying on manual exceptions.

What to verify: Confirm that governance is enforced in the platform itself, not just reflected in dashboards. If reviews, provisioning, revocation, and delegation still happen in separate control paths, treat the architecture as fragmented even if the UI is unified.

Common mistake: Treating migration to one platform as proof of convergence. The real test is whether the platform can preserve differentiated control for identities with different assurance, ownership, and expiry assumptions.

Practitioner takeaway: Re-evaluate whenever consolidation crosses identity classes, because the architectural question is not “Did we centralise?”, but “Did we preserve the right control semantics for each identity type?”

Related resources from NHI Mgmt Group

• Should organisations re-evaluate their identity security architecture after a major acquisition?
• Should security teams re-evaluate identity architecture after major platform consolidation?
• Should identity teams re-evaluate their NHI and AI governance after a major platform acquisition?
• Should organisations re-evaluate insider risk tools after platform consolidation?