Who should own governance when AWS Organizations and Identity Center SSO are used together for access control?

Ownership should sit with the central identity and security function, while platform teams manage implementation details and account-level access patterns. AWS Organizations and Identity Center SSO solve different parts of the problem, so governance must define who approves access, who audits it, and who can revoke it. Clear accountability prevents multiple systems from becoming multiple sources of truth.

Why This Matters for Security Teams

When AWS Organizations and Identity Center SSO are used together, the control question is not just technical provisioning. It is about who owns the policy decision, who enforces separation of duties, and who can prove access is still appropriate after an account, role, or business unit changes. The governance model must be explicit because the two services operate at different layers, and confusion there often creates duplicated approvals or missed revocations.

This is where identity governance intersects with AWS account structure. AWS Organizations governs the estate, while Identity Center governs human access patterns into that estate. If ownership is split informally, teams tend to assume someone else is reviewing group membership, permission sets, and cross-account role usage. That gap is exactly where over-privilege accumulates, which aligns with the broader NHI risk patterns documented in the Ultimate Guide to NHIs and the control expectations in NIST Cybersecurity Framework 2.0.

In practice, many security teams discover ownership failures only after a stale assignment, orphaned access path, or audit finding has already occurred, rather than through intentional governance design.

How It Works in Practice

The cleanest operating model is central governance with distributed implementation. The central identity or security function should own the policy framework, approval workflow, and periodic review standard. Platform teams can still manage AWS account structure, permission set design, and application-specific access patterns, but they should not be the final authority on who gets access.

That division matters because Identity Center is the user-facing access layer, while AWS Organizations defines the landing zones and account boundaries. In practice, governance should answer four questions: who approves a request, who configures the permission set, who reviews access on a schedule, and who revokes access when it is no longer needed. If those answers are not written down, access control becomes a shared responsibility in the worst sense: everyone is involved, nobody is accountable.

For practitioners, the most reliable approach is to treat Identity Center assignments as governed entitlements and AWS Organizations as the structural control plane. The identity function should define the approval matrix, require evidence for privileged access, and own joiner-mover-leaver processes. Platform teams should implement least privilege at the account and role level, but within centrally defined guardrails. This is consistent with the direction of the OWASP Non-Human Identity Top 10, even though the same governance logic also applies to human access paths.

NHIMG research shows why this matters: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges in the broader environment. Even though those figures are about NHI exposure, they illustrate the same failure mode governance is trying to prevent. Access becomes durable when nobody owns review and revocation. These controls tend to break down when multiple AWS accounts, separate business units, and manual exception handling are layered on top of each other because approvals and revocations stop matching the actual access graph.

Common Variations and Edge Cases

Tighter central governance often increases operational overhead, so organisations need to balance speed against control. That tradeoff becomes most visible in fast-moving platform teams that want autonomy for short-lived projects, sandboxes, or merger integration work.

Current guidance suggests a few common exceptions can be handled safely, but there is no universal standard for this yet. For example, platform teams may own predefined permission-set templates, while the central identity function owns the template catalog and approval rules. Likewise, a security operations team may own emergency break-glass procedures, but only under centrally defined logging, time limit, and post-use review requirements.

Another edge case is delegated administration across subsidiaries or regulated business units. In those environments, local teams may administer their own AWS accounts, yet the identity governance model still needs a single source of truth for entitlements and revocation authority. The key test is simple: if access can be granted in one system and removed in another, governance must define which system is authoritative and which team signs off. That principle is reinforced by NHIMG’s broader lifecycle guidance in the Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs and the audit focus in Ultimate Guide to NHIs — Regulatory and Audit Perspectives.

The model breaks down when organisations let account administrators approve their own Identity Center access, because that creates a circular control that is difficult to audit and easy to abuse.

Related resources from NHI Mgmt Group

• Who should own identity control evidence when multiple teams share access governance?
• Who should own answers about access control and identity governance in due diligence?
• How should security teams decide between LDAP and SSO for enterprise access control?
• Why do SSO deployments still need strong identity governance instead of relying on one login?