What should organisations do when software provenance and IAM are managed separately?

Why separate provenance and IAM creates a control gap

When software provenance and IAM are managed in different silos, organisations often get two partial controls instead of one trust model. Developer sign-in can be strong while repository authorship, commit integrity, and release attribution remain weak. The practical problem is that identity assurance must extend from human access into the artefact chain, not stop at the login screen.

That gap matters because provenance is only as trustworthy as the identities and credentials that can sign, approve, or publish code. If the same governance model does not cover developers, automation, and signing keys, the organisation can end up trusting artefacts whose origin cannot be proven even though access to the tools was authenticated.

How commit signing, identity proofing, and credential lifecycle fit together

The alignment point is the control plane, not the individual tool. Commit signing ties code to a signing identity, identity proofing establishes who or what is allowed to hold that identity, and credential lifecycle controls determine when that authority starts, rotates, and ends. Used together, they make source integrity part of identity governance rather than an afterthought in the build process.

This is where lifecycle discipline becomes essential. If signing keys, tokens, or service credentials outlive the identity that should own them, provenance checks can still show a valid signature while the underlying authority has drifted, been shared, or been reused elsewhere. The result is a provenance signal that looks complete but does not reflect current trust.

For organisations building modern delivery pipelines, this is also a workload-identity problem, not just a developer-account problem. A practical software supply chain should treat CI/CD automation, build systems, and release signing as governed identities with bounded authority, not as invisible plumbing. SLSA is useful here because it frames provenance as a verifiable property of the build path, not just the source repository.

What good integration looks like in practice

Good integration means one identity governance model covers both people and the software delivery mechanisms they operate. That usually includes proofing or approval for who can obtain signing authority, tightly controlled issuance for signing material, and revocation or rotation when access changes. Lifecycle Processes for Managing NHIs is a useful reference point for thinking about provisioning, rotation, and offboarding as one continuous lifecycle rather than separate operational chores.

It also means using the same operational expectations for human and non-human actors where they both influence source integrity. Build bots, release automation, signing services, and repository administrators should all be subject to ownership, review, and retirement decisions that are visible to the same governance team. Identity Security Programme Guide helps with that broader operating model, because it treats identity governance as a programme across human, non-human, and AI agent identities.

Where the environment is cloud-native, the provenance question often turns into a workload-identity question. Keyless or federated patterns reduce the risk of long-lived secrets anchoring build trust in static credentials. Cloud Workload Identity Guide is relevant because it shows how temporary, federated authority can replace persistent keys in delivery pipelines.

Risk and Threat Considerations

Separating provenance from IAM creates an attacker-friendly seam. If an adversary compromises a developer account, steals a signing secret, or abuses an overprivileged build identity, they may be able to produce artefacts that appear legitimate because the provenance signal is detached from the access governance that should constrain it. The failure is not just unauthorised access, but unauthorised authorship with valid-looking trust evidence.

Failure mechanism: The organisation authenticates users and services, but does not bind signing authority, repository permissions, and credential lifecycle into one governed trust chain. That allows stale, shared, or stolen credentials to keep producing trusted commits or release artefacts after the original access decision should have expired.

Impact: Malicious or compromised code can move through build and release workflows with lower detection probability, and incident response may struggle to prove which identity actually authorised the artefact. In practice, this increases the blast radius of a single identity compromise and weakens rollback, audit, and non-repudiation outcomes.

Practitioner Guidance

What to verify: Confirm that commit signing keys, repository privileges, and identity proofing records are governed together, not by separate teams with separate review cycles. The test is whether revoking an identity also invalidates its ability to produce trusted code artifacts, without relying on manual exception handling.

What to prioritise: Start with the identities that can publish, sign, merge, or release. Those are the points where authentication becomes source integrity, so they deserve the strictest lifecycle control, least privilege, and fastest revocation path.

Common mistake: Treating signed commits as proof of trust when the signing material may be long-lived, shared, or poorly owned. A signature is only meaningful if the identity behind it is current, unique, and governed.

Practitioner takeaway: If provenance and IAM are separate, close the gap by governing signing authority the same way you govern privileged access, because source integrity depends on identity controls that stay valid across the whole delivery chain.

Related resources from NHI Mgmt Group

• How do organisations operationalise NHI ownership at scale?
• What is the difference between human IAM controls and NHI governance?
• When should organisations treat an NHI as a high-priority risk?
• How can organisations reduce the blast radius of compromised agent identities?