Product security teams are accountable for making decisions across the full product surface, not just the application layer. That includes infrastructure settings, identity controls, deployment paths, and runtime environment. The practical requirement is clear visibility across components, so risk owners can make contextual decisions and document why a change is acceptable before release.
Why This Matters for Security Teams
Product security accountability becomes hard to argue only when teams treat infrastructure, identity, and application security as separate queues. In reality, release risk sits at the intersection of all three, so the accountable decision-maker must be able to assess how a change affects access, deployment paths, secret handling, and runtime behaviour together. That aligns with the control expectations in NIST Cybersecurity Framework 2.0, which treats governance and risk decisions as cross-functional, not siloed.
NHIMG’s Ultimate Guide to NHIs shows why this matters operationally: only 5.7% of organisations have full visibility into their service accounts, and 97% of NHIs carry excessive privileges. Those figures make it obvious that accountability cannot stop at the application boundary when the underlying identities and infrastructure often create the real blast radius.
In practice, many security teams only discover the ownership gap after a release introduces a credential exposure, a permissive role, or an infrastructure drift that no single team felt empowered to block.
How It Works in Practice
The accountable product security function should act as the decision broker across domains, while implementation owners provide the technical evidence. That means infrastructure teams explain the environment, identity teams explain who or what can act, and application teams explain the intended behaviour. Product security then decides whether the combined risk is acceptable, what compensating controls are required, and whether the change can ship. This is consistent with the governance model in the NIST SP 800-53 Rev 5 Security and Privacy Controls, which expects security outcomes to be managed through documented control ownership.
For overlapping risk decisions, the strongest practice is to evaluate the release as one system:
- identity scope, including human and non-human access paths
- infrastructure posture, such as network exposure, trust boundaries, and deployment permissions
- application controls, including input handling, authorization checks, and secrets usage
- runtime guardrails, especially where automation can chain actions across services
That is where NHI evidence becomes critical. NHIMG’s Top 10 NHI Issues and Ultimate Guide to NHIs both point to the same operational problem: over-privileged service accounts, weak rotation, and poor visibility make “application-only” approvals incomplete. A product security decision is only defensible if it records why the combined identity, infrastructure, and application posture is safe enough for release.
This guidance breaks down in highly decentralised platform models where teams can independently change roles, pipelines, and runtime policy without a single release gate, because accountability fragments faster than review evidence can be assembled.
Common Variations and Edge Cases
Tighter cross-domain approval often increases release friction, requiring organisations to balance speed against the cost of deeper review. That tradeoff is real, especially in teams using GitOps, ephemeral environments, or frequent infrastructure-as-code changes. Current guidance suggests the answer is not to centralise every technical decision, but to centralise the accountability for the final product risk call.
There is no universal standard for this yet, but the practical pattern is evolving toward shared evidence with a single accountable owner. For example, a platform team may own the cluster policy, a security engineer may own the exception analysis, and an application owner may own the control fix, while product security signs off on the release decision. That approach fits the governance direction in the NIST Cybersecurity Framework 2.0 and the supply-chain expectations emerging in the EU Cyber Resilience Act.
Edge cases usually appear when identity is outsourced, infrastructure is managed by a separate platform group, or an agentic workload can change its own environment. In those cases, product security still remains accountable for the decision, but the evidence standard must include runtime identity, not just static role design. That is why NHIMG’s 52 NHI Breaches Analysis is a useful reminder: when identity and infrastructure controls fail together, post-incident ownership questions arrive too late to help.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST CSF 2.0 and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM | Governance and risk management require clear decision ownership across overlapping product controls. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Overlapping identity and infrastructure risk often stems from weak NHI visibility and ownership. |
| OWASP Agentic AI Top 10 | A-03 | Autonomous or tool-using agents can amplify product risk across identity, app, and infrastructure layers. |
| CSA MAESTRO | GOV-1 | MAESTRO governance expects clear accountability for agentic and platform-risk decisions. |
| NIST AI RMF | GOVERN | AI RMF governance emphasizes accountability when AI-related controls affect product risk. |
Assign one accountable owner to approve cross-domain product risk and document the rationale before release.
Related resources from NHI Mgmt Group
- How should security teams prioritise identity governance when cloud, infrastructure, and application access are all changing at once?
- Who is accountable when Infrastructure as Code changes create compliance or security failures?
- Who is accountable for partner enablement when identity security programs expand across regions and industries?
- Who should be accountable for workload identity security across platform, identity, and security teams?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
