What is the difference between a persona-driven IGA design and a product-led IGA design?

Why This Matters for Security Teams

The difference matters because identity governance fails when the operating model is mismatched to how access is actually created, approved, and reviewed. A persona-driven design starts with identity reality: service accounts, workload identities, API keys, and privileged roles behave differently, so controls must reflect those patterns. A product-led design often inverts that logic, which can create gaps in ownership, missing entitlements, and brittle review workflows. NHI Mgmt Group notes that NHIs outnumber human identities by 25x to 50x in modern enterprises, and only 5.7% of organisations have full visibility into their service accounts in the Ultimate Guide to NHIs — What are Non-Human Identities.

That visibility gap is why many IGA programmes look complete on paper but underperform in practice. A tool-first rollout can optimise for connector coverage, workflow simplicity, or a generic access model while missing the real governance question: who or what needs access, under which operating conditions, and how that access should be revoked when the context changes. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is explicit that identity and access controls must be tied to organisational requirements, not assumed by tooling defaults.

In practice, many security teams discover the mismatch only after access reviews stall, offboarding breaks down, or audit evidence has to be reconstructed from multiple systems rather than through intentional design.

How It Works in Practice

Persona-driven IGA starts by defining the major identity classes and their governance needs before choosing workflows. For NHIs, that usually means separate treatment for application service accounts, CI/CD identities, integrations, bots, and privileged automation. Each persona has different lifecycle events, approvers, data sources, and evidence requirements. The objective is not to force all identities into one approval path, but to map the right control to the right identity type and risk level.

In a practical design, teams typically do four things:

• Inventory identity personas and classify them by function, ownership, and privilege.
• Map each persona to its source of truth, entitlement model, and review cadence.
• Define joiner, mover, and offboarding steps that match the identity’s lifecycle.
• Align reporting and attestations to actual operational risk rather than generic role names.

This is where persona-driven IGA also aligns more naturally with NHI governance. The Ultimate Guide to NHIs — The NHI Market captures the scale and diversity of modern NHI estates, which makes a one-size-fits-all product workflow difficult to sustain. Current guidance suggests using policy-driven access rules and system-level ownership, especially where secrets, tokens, and machine identities are involved, because those controls are auditable and easier to automate than ad hoc manual exceptions. NIST also treats access governance as part of a broader control system, not a narrow feature of the IGA platform itself.

Product-led IGA can still work when the organisation is small, identity types are few, and process maturity is high enough to absorb the tool’s assumptions. These controls tend to break down when hundreds of heterogeneous NHIs are created across CI/CD, SaaS, and cloud environments because the platform’s default data model cannot represent the identity lifecycle cleanly.

Common Variations and Edge Cases

Tighter persona modelling often increases upfront analysis and process design cost, requiring organisations to balance better governance against implementation speed. That tradeoff is real, and the best practice is evolving rather than universal. Some programmes use a hybrid model: persona-driven policy design with product-led execution for standardised workflows such as requests, attestations, and reporting.

Edge cases usually appear where identity ownership is distributed. Shared service accounts, vendor-managed integrations, and ephemeral workloads can resist clean persona assignment because the “user” is not a single team or person. In those cases, governance should focus on accountability, source system, and risk tier rather than trying to force a human-style organisational chart onto machine identities. This is especially important when secrets are embedded in pipelines or when access is provisioned indirectly through cloud roles and federated trust.

For teams building their programme, a useful test is simple: if the IGA platform cannot express the identity’s owner, purpose, expiry, and review trigger, the design is probably product-led in disguise. The underlying issue is not the tool itself, but whether the operating model was defined before the platform was selected. Organisations that start with a tool often end up retrofitting personas later, which usually costs more and produces weaker governance evidence.

Related resources from NHI Mgmt Group

• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between zero trust for users and zero trust for NHIs?