Identity security platforms need shared services, not siloed tools

At a glance

What this is: This blog sets out ten RFP-style questions for deciding whether an identity security offering behaves like a platform or a set of isolated tools.

Why it matters: It matters because IAM, PAM and NHI programmes fail operationally when audit, lifecycle, policy and automation are fragmented across products instead of shared.

Context

Identity security platforms are often judged on controls such as privileged access, least privilege, MFA and secret rotation, but that is only part of the question. The harder issue is whether the platform can centralise the services that make those controls consistent across products, identity types and teams.

This article frames platform strength as an operational governance problem, not just a security feature set. If logs, lifecycle events, policy decisions and automations live in separate silos, auditors, responders and administrators inherit more manual work, more errors and weaker visibility.

For IAM and NHI programmes, the practical test is whether shared services exist at the platform layer. Without them, even strong point tools can behave like disconnected controls with no common operating model.

Key questions

Q: How do you tell whether an identity security platform is actually a platform?

A: A real platform provides shared services that multiple products consume, including audit, lifecycle, policy, automation and correlation. If each tool keeps its own logs, rules and workflows, you have point solutions with integration, not a platform. The practical test is whether one operating layer governs identity decisions consistently across the stack.

Q: Why does shared audit and correlation matter for identity security?

A: Because auditors and investigators need one coherent evidence trail, not separate exports from every product. Shared audit and correlation reduce manual reconciliation, speed root cause analysis and make cross-domain behaviour visible. Without them, organisations can have strong controls but still fail to prove what happened or respond quickly enough.

Q: What goes wrong when lifecycle management is handled product by product?

A: Provisioning drift, orphaned accounts and lingering permissions appear when each tool interprets joiner-mover-leaver events differently. Shared lifecycle logic keeps deprovisioning and entitlement changes consistent across vaults, cloud services and server access. That reduces errors and makes recertification and offboarding far more reliable.

Q: How should teams evaluate identity management platforms for lifecycle automation?

A: Start with mover-flow testing, not joiner-flow demos. The platform should handle promotions, contractor conversions, leave events, role reversions, and terminations while keeping approvals, entitlements, and audit logs consistent. If those transitions require manual cleanup, lifecycle automation is shallow and the governance model will not scale.

Technical breakdown

Shared audit pipelines and signal exchange

A platform-level audit layer does more than store logs in one place. It normalises identity events from multiple products into a common schema so compliance teams and responders can reconstruct who did what, when and under which controls. The article also points to standardised communication via the OpenID Foundation’s Shared Signals Framework, which matters because shared signals enable real-time risk propagation between systems rather than delayed log stitching. This is the difference between isolated event records and a coherent identity evidence trail that can support continuous access evaluation and Zero Trust decisions.

Practical implication: demand a common audit pipeline that can consume and publish identity events across products and external tools.

Lifecycle modelling across joiner, mover and leaver events

Lifecycle services become valuable when one policy engine governs provisioning, deprovisioning and entitlement changes across products. In the article’s model, joiner-mover-leaver events should flow through shared lifecycle logic so that a cloud entitlement, a vault credential and a server login are all adjusted by the same underlying rule set. Without that shared service, teams end up with product-specific scripts, inconsistent timing and stale access that persists after role changes. The governance problem is not simply whether lifecycle exists, but whether every product consumes the same lifecycle model instead of creating its own.

Practical implication: verify that lifecycle changes are exposed as APIs or triggers that every connected product must use.

Correlation, shared visibility and identity blast radius

Correlation is the platform service that turns separate access events into a single investigative chain. The article’s point is that a login in one system, a privileged action in another and a cloud access event in a third should be linked automatically, not manually reconstructed after the fact. That shared view reduces time to root cause and makes lateral movement easier to spot. The underlying concept is identity blast radius, the amount of damage an identity can create when its activity is visible only in fragments. Platform architecture should shrink that blast radius by making cross-domain behaviour searchable and connected.

Practical implication: insist on correlation services that link identity activity across vault, server, cloud and IdP records.

Breaches seen in the wild

• Scania insurance portal breach 2025: An attacker used an external user login, likely stolen by infostealer malware, to take insurance claim documents from a Scania portal.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Shared services are the real definition of a platform. Identity security products become a platform only when audit, lifecycle, policy, automation and visibility are consumed as common services rather than recreated in each tool. That matters because fragmented services force teams to reconcile inconsistent data and policy outcomes after the fact. The practitioner conclusion is simple: evaluate the operating layer, not the feature list.

Platform fragmentation creates governance drift. When each product maintains its own logs, lifecycle logic or policy engine, the organisation gets multiple versions of identity truth. That breaks auditability, slows investigations and makes access decisions depend on where the control was enforced. The field should treat consistency as a first-class security requirement, not an administrative convenience.

Identity blast radius is the right lens for shared visibility. The article shows that connected audit and correlation services matter because they compress the time between action and understanding. Without them, identity activity is scattered across products and the blast radius of a compromise is larger simply because nobody can see the chain quickly enough. Practitioners should measure whether the platform reduces investigative fragmentation across domains.

Lifecycle coherence is becoming a platform differentiator. Joiner-mover-leaver handling cannot remain a product-by-product implementation if identity programmes want predictable deprovisioning, fewer errors and cleaner recertification. The platform pattern is shared lifecycle logic that every consuming product obeys. That is the governance model practitioners should push for when they evaluate tool consolidation.

Interoperability now extends to AI-initiated actions. The article’s discussion of shared signals and MCP reflects a broader shift: identity platforms must be able to govern machine and AI-driven interactions without custom one-off connectors everywhere. That does not make every AI workflow autonomous, but it does make shared policy and audit services more important. Practitioners should treat interoperability as a governance requirement, not just an integration convenience.

What this signals

Identity platform evaluation is now an operating-model question. Teams should stop asking only which control a tool provides and start asking whether the control is shared, observable and reusable across the platform. That shift matters because operational consistency is what turns security features into governable identity services.

Shared services reduce identity governance drag. When audit, lifecycle and policy are centralised, recertification and investigation work becomes less manual and more defensible. The value is not abstract platform elegance, but fewer edge cases where one product behaves differently from the rest.

Open standards are part of the platform test. If a vendor cannot exchange identity events cleanly with adjacent systems, it will push teams back toward brittle point-to-point integration. Shared Signals Framework and MCP are useful markers here because they show whether the platform can participate in a broader identity operating model.

For practitioners

• Demand a shared audit layer Require every product to publish into one centralised logging and audit service so compliance evidence and incident reconstruction do not depend on manual export stitching.
• Test lifecycle coherence across products Check that joiner-mover-leaver events trigger the same lifecycle logic for vault credentials, cloud entitlements and server logins instead of separate scripts per tool.
• Validate cross-domain correlation Confirm that identity actions from the IdP, vault, server and cloud are linked into a single investigative trail that analysts can search and replay.
• Verify platform-wide policy enforcement Ask whether one policy engine governs step-up controls, MFA at depth and context-aware authorisation across all consuming products, not just inside each product.
• Check interoperability for AI-driven workflows Determine whether the platform can exchange identity and risk signals with external systems through open standards such as the Shared Signals Framework and MCP.

Key takeaways

• The article argues that identity security should be judged by shared services, not by whether individual tools can enforce familiar controls in isolation.
• Centralised audit, lifecycle, policy and correlation services reduce manual reconciliation, inconsistent governance and slow investigations.
• For practitioners, the key question is whether the platform creates one operating layer that multiple products and external systems can safely consume.

Key terms

• Identity Security Platformisation: The consolidation of identity capabilities such as IAM, PAM, secrets, and NHI functions into a single operating model. It can simplify procurement and visibility, but it also risks blurring control ownership unless enforcement, evidence, and lifecycle responsibilities remain separate and testable.
• Shared Service: A shared service is a common platform, gateway, or operational capability used by multiple teams or organisations. In security incidents, it becomes a high-leverage dependency because compromise can affect more than one environment. Its risk depends on isolation, access design, and how much trust is concentrated in the shared layer.
• Identity correlation: Identity correlation is the process of linking multiple account records to one governed subject. It lets IAM and IGA teams understand that separate usernames, principals, or emails may belong to the same employee or workload, which is essential for access review, offboarding, and entitlement analysis.
• Lifecycle Modelling: Lifecycle modelling is the logic that turns joiner-mover-leaver events into coordinated identity changes across systems. It helps teams apply one consistent decision to provisioning, revocation, downgrade, and deactivation instead of relying on separate scripts and manual updates.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.