Subscribe to the Non-Human & AI Identity Journal

Who should own identity security in a growing company?

Ownership should sit with the security and identity function, but it must be operationally shared with engineering, IT, and business leaders. Growing companies fail when identity is treated as a side task for one generalist. The accountable model is one where lifecycle, access reviews, and authentication standards are centrally governed and locally enforced.

Why This Matters for Security Teams

Who owns identity security is really a question about accountability, not who clicks the buttons. In a growing company, identity sprawl quickly outpaces informal processes, and the first signs of failure are usually leaked secrets, over-privileged service accounts, and access reviews that nobody can reliably complete. NIST Cybersecurity Framework 2.0 frames identity as part of governance and protection, but the operating model still has to be made real inside the business.

NHIMG research shows why this cannot sit as a side task: in the Ultimate Guide to NHIs, only 5.7% of organisations report full visibility into service accounts, while 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. That is a management problem as much as a technical one. In practice, many security teams encounter identity drift only after a production incident or a failed audit, rather than through intentional governance.

How It Works in Practice

The most effective model is central ownership with distributed execution. Security or identity engineering should define standards for authentication, lifecycle management, secret handling, and privileged access, while IT and engineering enforce those standards in systems they operate. That division matters because identity security breaks when each team invents its own rules for onboarding, offboarding, and exceptions.

For human identities, that usually means policy-driven joiner-mover-leaver processes, MFA standards, role design, and access review cadence. For non-human identities, it also means inventorying service accounts, API keys, tokens, and certificates, then assigning an owner to each one. NHIMG’s State of Non-Human Identity Security highlights the scale of the issue: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 1 in 4 are already investing in dedicated NHI security capabilities. That points to a practical operating model, not a purely theoretical one.

  • Security owns the policy: passwordless direction, MFA requirements, secret rotation, and privileged access rules.
  • Engineering owns implementation: service-to-service auth, pipeline secrets, application ownership, and code-level controls.
  • IT owns directory and lifecycle operations: workforce provisioning, deprovisioning, and identity source-of-truth hygiene.
  • Business leaders own risk acceptance: approving exceptions, funding tooling, and enforcing accountability in their departments.

Frameworks such as the NIST Cybersecurity Framework 2.0 support this by tying identity to governance and access control outcomes, but they do not replace clear ownership. The practical test is simple: one team should be able to answer who owns every identity, who can approve access changes, and who is responsible when a secret is exposed. These controls tend to break down when ownership is split across matrix teams with no single accountable manager because exceptions accumulate faster than reviews can clear them.

Common Variations and Edge Cases

Tighter central control often increases process overhead, requiring organisations to balance speed against assurance. That tradeoff is real in startups and fast-growing product teams, where engineers may resist central gates that slow releases. Current guidance suggests keeping policy central while allowing implementation patterns to vary by system criticality, but there is no universal standard for how much local autonomy is acceptable.

Another edge case is merged identity and platform teams. That can work if the function has enough independence to enforce standards, but it becomes risky when the same people who build systems also approve their own exceptions. Mature programmes usually separate policy ownership from day-to-day administration, even if the same department holds both functions.

Identity security also needs different handling for NHIs than for employees. NHIs outnumber human identities by 25x to 50x in modern enterprises, so a human-centric process will fail unless it includes service accounts, CI/CD credentials, and third-party OAuth grants. The Top 10 NHI Issues and the 52 NHI Breaches Analysis both reinforce the same lesson: ownership must be explicit, or identity risk becomes diffuse and unmanaged.

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
NIST CSF 2.0 GV.OC Identity ownership is a governance and accountability issue.
NIST CSF 2.0 PR.AC Access control is the operational core of identity security.
OWASP Non-Human Identity Top 10 NHI-01 Identity sprawl and poor ownership drive non-human identity exposure.

Assign a single accountable owner for identity risk and define how security, IT, and engineering share execution.