Who should own identity governance in a cloud-first organisation, security or platform teams?

Ownership should be shared, with security setting policy and assurance requirements while platform and infrastructure teams manage day-to-day implementation. Cloud-first access decisions often sit closest to the platforms where change happens, but governance still needs central oversight for consistency, auditability, and least privilege. Clear decision rights matter more than organisational labels.

Why This Matters for Security Teams

In a cloud-first organisation, identity governance is not just an access-review exercise. It is the control plane for who can deploy, modify, observe, and automate production systems. If security owns only the policy and platform teams own only the implementation, gaps appear quickly at the handoff points: service accounts, CI/CD tokens, cloud role assumptions, and ephemeral workload access. The risk is amplified when teams treat NHIs like user accounts instead of machine-held trust relationships, a failure pattern covered in Ultimate Guide to NHIs.

The practical problem is not organisational title, but decision rights. Security usually needs to define minimum standards, exception handling, and assurance evidence, while platform teams need enough authority to implement those standards at the speed cloud change demands. That balance aligns with the control intent in the NIST Cybersecurity Framework 2.0, where governance and operational ownership are distinct but connected. NHIMG research also shows why this matters now: only 1.5 out of 10 organisations are highly confident in securing NHIs, and lack of credential rotation is the top cited attack cause. In practice, many security teams discover the ownership gap only after a leaked token, over-privileged role, or forgotten service principal has already become an incident.

How It Works in Practice

The most workable model in cloud-first environments is shared ownership with explicit boundaries. Security sets policy, risk tolerance, review criteria, and escalation paths. Platform and infrastructure teams execute those requirements where the identities actually live: cloud IAM, Kubernetes, CI/CD, secrets management, and workload orchestration. This is the point where identity governance becomes operational, not just advisory, and where NHIs need lifecycle control from issuance through rotation to revocation, as outlined in Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs.

A practical operating model usually includes:

• Security owns policy standards for least privilege, TTL, rotation, and audit evidence.
• Platform teams own implementation in IAM, cloud orgs, Kubernetes, and deployment pipelines.
• Application and product teams request access through controlled workflows, not ad hoc tickets.
• Governance reviews are automated where possible, with exceptions time-boxed and tracked.

For cloud-native access, the strongest pattern is to prefer workload identity and short-lived credentials over static secrets. The goal is to bind access to the identity of the workload, not to a reusable password or key. That principle is consistent with the operational direction in the Top 10 NHI Issues and with current identity guidance from the CISA Zero Trust Maturity Model. The governance question then becomes who can approve which entitlements, for how long, and with what evidence that the entitlement is still needed. These controls tend to break down when platform teams are asked to move faster than the policy baseline allows because exceptions then become the default operating model.

Common Variations and Edge Cases

Tighter governance often increases delivery overhead, so organisations have to balance speed against control maturity. That tradeoff becomes visible in platform engineering, where teams may resist central approval gates if they slow deployments or break automation. Current guidance suggests the answer is not to centralise every decision, but to centralise standards and decentralise execution within clear guardrails. There is no universal standard for this yet, especially in organisations with multiple clouds, shared services, and strong DevOps autonomy.

Edge cases usually appear in three places. First, legacy systems may still require long-lived credentials, which means security and platform teams need a documented exception process and a retirement plan. Second, third-party integrations can blur ownership because SaaS admin roles, OAuth grants, and vendor-managed tokens often sit outside the cloud platform team’s direct control. Third, highly regulated environments may require security to retain stronger approval authority for privileged roles, even if platform teams manage the day-to-day mechanics. NHIMG’s State of Non-Human Identity Security shows how common this visibility gap remains.

For governance to hold, the question is not whether security or platform teams “own” identity in the abstract. The better question is who owns policy, who owns implementation, and who is accountable when a workload credential or privilege path is overextended.

Related resources from NHI Mgmt Group

• How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?
• How do security teams decide whether to prioritise NHI governance, workload identity protection, or identity threat detection first?
• Why do cloud security and identity governance programmes still need internal controls after a platform earns FedRAMP Moderate authorization?
• How should identity security teams apply secure-by-design principles to cloud-native governance platforms?