How should security teams and engineering teams split responsibility for identity security in modern infrastructure?

How Should Security Teams and Engineering Teams Split Responsibility?

The cleanest split is between policy authority and implementation ownership. Security teams should define the access model, approval thresholds, monitoring expectations, and evidence requirements, then verify that those controls are actually working. Engineering teams should design the systems, workflows, and automation that enforce those requirements in day-to-day delivery and operations. That division matters because modern infrastructure is built around identities, tokens, services, and automated workflows rather than fixed network perimeters.

In practice, the teams that build the platform are usually the only ones able to place controls close enough to the workload to be effective. Security can still set the boundary conditions, but it should not be expected to handcraft every access path or manage every integration pattern. A useful reference point is the control structure in NIST SP 800-53 Rev 5 Security and Privacy Controls, which separates governance expectations from technical enforcement in a way that maps well to shared responsibility.

For identity-heavy environments, the practical question is not who “owns IAM” in the abstract, but who can answer for a given control when a secret is exposed, a service account is over-privileged, or a workload can authenticate outside its intended scope. NHIMG’s Ultimate Guide to NHIs is useful here because it frames the governance problem around lifecycle, rotation, visibility, and offboarding rather than a narrow tooling discussion.

Security teams that stay at the policy layer without getting evidence from engineering usually discover gaps only after access has already drifted beyond design intent.

Where the Split Breaks Down in Real Infrastructure

The split works best when it is explicit, measurable, and tied to concrete identity assets. It breaks down when security teams write rules without understanding how platforms actually authenticate, or when engineering teams ship access paths without a control objective they must satisfy. In modern cloud and platform environments, identities move across CI/CD, workloads, APIs, and third-party integrations, so ownership has to follow the control point rather than the org chart.

A practical model is to let security own the decision criteria and assurance model, while engineering owns the implementation path and operational reliability. Security decides what “good” looks like: short-lived credentials, least privilege, rotation expectations, logging coverage, and exception handling. Engineering translates that into platform guardrails, service templates, secret-handling patterns, and defaults that make the secure path the easy path. That arrangement is strongest when teams can test it through measurable outcomes instead of policy language alone.

One reason this division matters is that identity failures are often lifecycle failures. If credentials are long-lived, hidden in code, or scattered across systems, the owning team may think the control exists even when no one can prove rotation, revocation, or scope reduction actually happened. NHIMG research on non-human identity posture shows why this matters: long-lived secrets, weak rotation, and excessive privilege are common failure patterns, not edge cases. The operational lesson is that engineering must build for revocation and renewal as first-class behaviours, not as after-the-fact cleanup.

• Security should define the minimum evidence needed to trust an identity control, such as logs, review records, or automated test results.
• Engineering should own the implementation details that make those evidentiary checks possible inside delivery pipelines and runtime platforms.
• Both teams should agree on exception handling, because emergency access often becomes permanent when no one owns the expiry path.

This model tends to fail when identity controls are treated as a central team ticket queue instead of a platform property embedded in the systems that issue and use access.

Common Edge Cases and Ownership Tensions

Tighter identity governance often increases delivery friction, so organisations have to balance speed against assurance. The hardest cases are shared services, platform teams, vendor-connected workflows, and machine-to-machine access, where a single credential can affect many downstream systems and multiple teams may believe someone else owns the risk.

There is no universal standard for exactly where every responsibility stops, but current guidance suggests using three questions to settle disputes: who defines the control objective, who can implement it in the system, and who can prove it is still effective over time. If security cannot validate the outcome, the control is only a design intent. If engineering cannot operate it reliably, the control will degrade into exceptions and manual bypasses.

Edge cases also appear when identity decisions are embedded in application code, infrastructure templates, or orchestration logic. In those situations, engineering may need to own the technical mechanism, while security retains authority to reject designs that create excessive standing privilege or unreviewed trust expansion. The most common mistake is assigning responsibility only at incident time, when the actual failure was a missing ownership model during build and change.

Practitioner Guidance: Security teams should prioritise control objectives, evidence requirements, and exception governance; engineering teams should prioritise secure defaults, automation, and revocation-ready implementation. The key decision rule is simple: if a team cannot explain how access is granted, reduced, monitored, and removed in its own system, it does not truly own the control.

Practitioner takeaway: The split should follow the control point, not the reporting line; security owns trust decisions and assurance, while engineering owns the machinery that makes those decisions real.

Related resources from NHI Mgmt Group

• How should security teams centralise infrastructure access controls for FedRAMP without disrupting engineering operations?
• What breaks when infrastructure access controls are split across security, engineering, and compliance teams?
• How should security teams implement identity governance when access reviews, role changes, and approvals are spread across many apps and teams?
• How should security teams detect shadow app usage from identity provider logs without waiting on manual review?