Who is accountable for reducing product security risk in identity and governance platforms?

Why This Matters for Security Teams

Identity and governance platforms sit at the centre of access decisions, so a weakness in the product becomes a control failure everywhere it is deployed. When vendors ship insecure defaults, weak patching, or opaque vulnerability handling, the buyer inherits risk that cannot be fully removed through configuration. That is why product security accountability belongs to the software producer, while the customer remains responsible for safe deployment and oversight.

This is not a theoretical split. NHIMG’s Top 10 NHI Issues and 52 NHI Breaches Analysis both show how identity control gaps often become enterprise-wide incidents once a platform is over-trusted. The NIST Cybersecurity Framework 2.0 reinforces that governance depends on clear ownership, but secure-by-design expectations are now also shaped by regulatory pressure such as the EU Cyber Resilience Act.

In practice, many security teams discover vendor accountability only after a default setting, delayed patch, or undocumented dependency has already created exposure.

How It Works in Practice

Secure-by-design product accountability means the vendor must build the platform so it resists predictable abuse before customers ever touch a setting. That includes secure defaults, hardened authentication flows, timely patch release, clear disclosure channels, dependency management, and documentation that lets buyers make informed deployment decisions. It also means the vendor should publish a vulnerability intake process and define how quickly high-risk issues are assessed and remediated.

For buyers, accountability does not disappear. Security teams still need to govern configuration, restrict administrative access, review integrations, and validate whether product features are being used safely. In other words, the vendor owns product security in the build and maintenance phases, while the customer owns operational controls in the deployed environment. Current guidance suggests this split is strongest when contractual language, security attestations, and patch SLAs are aligned with actual product risk.

Practitioners should look for evidence that the vendor can answer basic assurance questions. Does the platform ship with least-privilege defaults? Are secrets handled with rotation support? Are audit logs complete enough for incident response? Are upgrade paths documented and backward compatibility risks called out? NHIMG’s Ultimate Guide to NHIs and the Regulatory and Audit Perspectives section are useful for translating those expectations into procurement and control language.

This model maps well to NIST SP 800-53 Rev 5 Security and Privacy Controls, which separates system development responsibilities from operational control enforcement, and it is reinforced by the OWASP NHI Top 10 because identity products often fail through privilege design, not just implementation bugs. These controls tend to break down when customers adopt heavily customised, self-hosted, or air-gapped deployments because patch cadence, telemetry, and shared responsibility boundaries become harder to enforce.

Common Variations and Edge Cases

Tighter vendor accountability often increases procurement friction, audit effort, and contract negotiation time, requiring organisations to balance faster adoption against stronger assurance.

There is no universal standard for this yet, so the practical answer varies by deployment model. In SaaS identity platforms, vendor responsibility is easier to define because the producer controls most of the runtime environment. In self-hosted or hybrid platforms, the customer may also inherit hardening and patching obligations, but that does not remove the vendor’s duty to ship secure software and disclose known risks. Best practice is evolving toward shared accountability with explicit boundaries.

Edge cases appear when a buyer disables secure defaults, ignores upgrade guidance, or connects the platform to risky third-party plugins. In those situations, the vendor still owns product quality, but the customer can become responsible for avoidable exposure. A mature procurement process should therefore separate product defects from deployment misconfiguration and track both. NHIMG’s Lifecycle Processes for Managing NHIs helps clarify where lifecycle control ends and platform assurance begins.

Related resources from NHI Mgmt Group

• Who is accountable for product security decisions when infrastructure, identity, and application risk overlap?
• Why do automated infrastructure platforms increase identity governance risk if they are left unchecked?
• How should security teams measure whether identity governance is actually reducing risk?
• How should security teams evaluate unified identity platforms for governance risk?