Who is accountable when unsigned software reaches production?

Accountability sits with the owners of the release process, the platform controls, and the governance team that allowed the exception path to exist. In software supply chains, release integrity is an operating model issue, not just a development issue. NIST Cybersecurity Framework 2.0 helps structure that accountability across govern, protect, and respond.

Why This Matters for Security Teams

Unsigned software in production is not just a build problem, it is a release integrity and accountability problem. If a team can bypass signing, the organisation has already lost the assurance that the artifact is what it claims to be, and incident response becomes a chain of exception reviews. NIST Cybersecurity Framework 2.0 makes that accountability explicit across governance, protection, and response, while the NHI context shows how often control gaps appear in the release path itself. NHI Mgmt Group reports that 96% of organisations store secrets outside secrets managers in vulnerable locations, which is one reason release pipelines remain exposed to tampering and unauthorized deployment paths. See the Ultimate Guide to NHIs — The NHI Market and NIST Cybersecurity Framework 2.0 for the broader control model. In practice, many security teams discover unsigned releases only after a deployment exception has already become routine.

How It Works in Practice

Accountability starts by mapping who owns each control in the release chain, not just who wrote the code. The release owner should be accountable for enforcing signing requirements, the platform team for preventing unsigned artifacts from reaching deploy stages, and the governance function for approving any exception path and setting its expiry. That means the question is less “who pushed it?” and more “who allowed a path that accepted it?”

Operationally, mature teams treat signing as a gating control, not an advisory check. Common mechanics include:

• Artifact signing at build time, with verification required before promotion to runtime.
• Policy enforcement in CI/CD so unsigned images, packages, or binaries fail closed.
• Short-lived, tightly scoped release credentials for the pipeline itself, paired with traceable workload identity.
• Exception logging with named approvers, business justification, time limits, and automatic review.

This is where identity governance and software supply chain controls overlap. If the pipeline uses long-lived secrets, shared service accounts, or weak separation between build and deploy privileges, the release path becomes easy to bypass. The same NHI issues documented in Ultimate Guide to NHIs — The NHI Market often show up as unsigned or unverifiable release artifacts. The practical standard is to make signature verification automatic, non-optional, and auditable, then assign a clear owner for every exception. These controls tend to break down when organisations allow manual hotfix deployment into production because the exception path bypasses the normal verification gate.

Common Variations and Edge Cases

Tighter signing enforcement often increases release friction, so organisations have to balance delivery speed against assurance and auditability. There is no universal standard for every exception model, but current guidance suggests exceptions should be rare, time-bound, and reviewed after the fact.

One common edge case is emergency remediation. In those situations, teams may permit a temporary bypass, but the bypass should still require named approval, full logging, and a post-incident retrospective that determines whether the control failed or was simply ignored. Another variation is third-party software, where accountability shifts to procurement, vendor risk, and platform governance as much as engineering. If unsigned or unverified artifacts are accepted from external suppliers, the receiving organisation still owns the risk.

The hardest cases are legacy systems and disconnected deployment environments, where retrofitting signing can be technically messy. Even there, the answer is not to abandon assurance but to document compensating controls, reduce the exception window, and define who is accountable when the control cannot be enforced. For broader governance context, NIST CSF 2.0 remains the right anchor because it ties release integrity to enterprise accountability, not just developer discipline.

Related resources from NHI Mgmt Group

• Who is accountable when a production model drifts below approved thresholds?
• Who is accountable when identity misuse disrupts production operations?
• Who is accountable when a platform breach reaches campus identity systems?
• Who is accountable when poisoned training data reaches production?