Ownership should sit with the teams running the platform, but the policy model should be shared with IAM, security engineering, and compliance. Platform teams own the technical controls, while identity teams define review, approval, and lifecycle requirements. If ownership is unclear, access reviews, drift remediation, and exception handling will all fail at handoff.
Why This Matters for Security Teams
Internal developer platforms concentrate high-value identity objects in one place: service accounts, CI/CD tokens, workload credentials, and privileged automation paths. If ownership is blurred, the platform can drift into “shared responsibility” in name only, with nobody accountable for lifecycle decisions, exception approvals, or drift remediation. That becomes a governance problem, not just an engineering one.
Current guidance suggests the platform team should own the technical controls because it operates the system of record for how identities are created, scoped, rotated, and revoked. Identity and security teams should still define the policy model, review standards, and audit criteria. The distinction matters because access sprawl in developer platforms often emerges faster than human reviewers can track.
NHIMG’s research shows this is not theoretical: only 5.7% of organisations have full visibility into their service accounts, and 71% of NHIs are not rotated within recommended time frames. That combination makes unclear ownership especially dangerous when platform automation can mint credentials at machine speed. In practice, many security teams discover the ownership gap only after access reviews stall, not through a deliberate governance design.
How It Works in Practice
The cleanest operating model is a three-way split: platform engineering implements the controls, IAM or identity governance defines the rules, and security/compliance verifies that the rules are being enforced. The platform team should manage the technical lifecycle for NHI objects inside the developer platform, including provisioning, scoping, TTL settings, rotation hooks, logging, and revocation. Identity teams should not own every workflow detail, but they should own the policy standard that says what “good” looks like.
That policy standard should cover questions such as: which identities require approval, which can be self-service with guardrails, what evidence is needed for reviews, and when exceptions expire. For internal developer platforms, this is best treated as a runtime governance problem rather than a one-time design review. NIST’s Cybersecurity Framework 2.0 is useful for structuring accountability across governance, protect, detect, and respond, while NHIMG’s Ultimate Guide to NHIs emphasizes lifecycle discipline for non-human identities.
In practice, this usually means:
- Platform teams own creation, rotation, and revocation workflows inside the IDP.
- IAM teams define approval thresholds, review cadence, and policy exceptions.
- Security engineering validates logging, monitoring, and escalation paths.
- Compliance consumes evidence, rather than manually operating the control.
Where this works best is when the platform exposes identity events through APIs and policy-as-code, so reviews and revocations can be automated. These controls tend to break down when the internal developer platform spans multiple clusters, cloud accounts, and legacy CI/CD systems because identity state fragments across tools.
Common Variations and Edge Cases
Tighter governance often increases operational overhead, so organisations have to balance faster developer self-service against stronger review and auditability. There is no universal standard for this yet, especially when platform teams also run golden paths, templates, and ephemeral environments that create identities on demand.
One common variation is central IAM ownership of every approval, which sounds clean but usually fails in practice because IAM does not see the full runtime context of the platform. Another is full delegation to platform engineering with no policy oversight, which often produces inconsistent expiry rules and weak exception handling. The better model is federated ownership with a single accountable technical owner for the platform and a separate policy owner for governance.
This becomes more complicated when the internal developer platform supports machine-generated credentials, cross-account access, or third-party integrations. NHIMG’s research notes that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly identity scope can extend beyond the platform boundary. In those environments, current guidance suggests treating offboarding, emergency revocation, and exception expiry as mandatory controls, not optional hygiene.
For teams looking to formalise this, the practical question is not “who approves access” but “who can prove the identity lifecycle is controlled end to end.” If that answer changes from one platform to another, governance will become inconsistent and audits will expose the gap.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Covers lifecycle control of non-human identities inside platforms. |
| NIST CSF 2.0 | GV.OV-01 | Governance oversight is needed to define accountable ownership. |
| NIST CSF 2.0 | PR.AC-4 | Access permissions must be managed and reviewed centrally. |
Assign platform teams to enforce creation, rotation, and revocation with NHI-03 as the lifecycle baseline.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
