Separate policy and assurance by stakeholder type, even if the platform is shared. The access path, verification level, consent handling, and audit expectations should reflect whether the subject is a citizen, a vendor, or another government entity.
Why shared identity platforms still need separate stakeholder policy
A single platform can reduce duplication, but it should not collapse the policy model. Citizen, business, and agency identities usually represent different trust boundaries, consent expectations, proofing strengths, and audit obligations. When teams treat them as one population, they often end up giving the same login experience to very different assurance needs, which creates avoidable governance and access risk.
The practical goal is to keep the platform shared while separating the decision rules. That means the identity source, authentication, and downstream entitlements may sit in the same technology stack, but policy should branch by stakeholder type before access is granted or data is exposed.
How policy should differ by stakeholder type
Citizens generally need the strongest focus on privacy, consent, and proportionate verification. Business identities usually require stronger organisation validation, delegated administration, and clearer role or entitlement boundaries. Agency identities should reflect inter-government trust, service-to-service assurance, and tighter auditability, especially where one public body is acting on behalf of another.
That separation is not just an administrative preference. It changes what evidence you accept, how you step up authentication, which attributes you trust, and what you log for later review. Shared-platform design works best when the platform provides common plumbing and the policy layer enforces different rules for each stakeholder class.
- Citizen flows should minimise data collection and make consent and purpose clear.
- Business flows should verify legal entity context and control who can act for the organisation.
- Agency flows should emphasise federation, delegation, and traceable administrative action.
What to standardise, and what to keep distinct
Standardise the platform capabilities that are reusable, such as federation, session management, logging, and lifecycle workflows. Keep distinct the controls that carry different assurance meaning, such as identity proofing level, recovery process, consent capture, entitlement review, and step-up authentication. If those are flattened into one “default” policy, the platform may become easier to operate but harder to defend.
This is where a Identity Convergence Guide is useful, because convergence can simplify operations without implying uniform treatment. For public-sector use cases, Public Sector Identity Security Guide helps frame why citizen services, government workers, and partner organisations should not inherit identical assurance decisions.
Risk and Threat Considerations
Shared platforms fail when a policy shortcut for one stakeholder type is silently reused for another. The result can be excessive access, weak identity proofing, consent drift, or audit records that do not match the real accountability model. In mixed environments, that becomes both a security issue and a governance issue because the same platform now protects relationships with different legal and operational meaning.
Failure mechanism: Teams create one “universal” access policy, then reuse it across populations with different trust assumptions, which allows lower-assurance identities to inherit controls intended for higher-assurance ones.
Impact: The organisation can expose citizen data, over-authorise business users, or weaken inter-agency trust, and investigators may later be unable to prove who was entitled to act, under what assurance level, and for what purpose.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5, CIS Controls v8 and CSA Cloud Controls Matrix set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Covers assurance levels and identity proofing differences across user populations. |
| Recommendation — Align proofing and authenticator strength to the assurance level required for each stakeholder type. | ||
| NIST SP 800-53 Rev 5 | IA-8 — Identification and Authentication (Non-Organizational Users) | Citizen and external business identities need distinct external-user authentication handling. |
| AC-6 — Least Privilege | Different stakeholder classes should receive different entitlement scope even on one platform. | |
| Recommendation — Apply IA-8 to enforce stronger authentication and onboarding for non-organizational identities. Use AC-6 to keep access scoped to the minimum each stakeholder class needs. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Shared platforms require policy separation so access decisions reflect user type and purpose. |
| Recommendation — Define access rules by stakeholder class and enforce them consistently across the shared platform. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | Control and review of access paths is central when one platform serves multiple identity populations. |
| Recommendation — Separate account and access management rules by identity population and review them regularly. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | Cloud identity governance must distinguish assurance, delegation, and lifecycle across populations. |
| Recommendation — Segment IAM policy by stakeholder type so lifecycle and access governance stay population-aware. | ||
Practitioner Guidance
What to prioritise: Define the stakeholder split before implementation, not after launch. The first design decision should be which attributes, proofing steps, and consent rules vary by population, because that determines whether the platform can support differentiated policy cleanly.
What to verify: Check that recovery, delegated administration, and audit logging are partitioned by stakeholder type. A shared platform is only defensible if the assurance path for a citizen cannot accidentally be reused for a vendor or an agency operator without an explicit policy decision.
Common mistake: Treating “single sign-on” as proof that the identity model is unified enough. The interface may be unified, but the assurance model still has to be population-aware.
Practitioner takeaway: Shared infrastructure is fine, shared trust assumptions are not, teams should converge the platform, but preserve separate policy, evidence, and audit logic for each stakeholder class.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 8, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org