Why does endpoint-based signing weaken Zero Trust for digital trust workflows?

Why This Matters for Security Teams

Endpoint-based signing looks convenient, but it shifts trust to the device layer, where malware, misconfiguration, and uncontrolled admin access are hardest to contain. That directly conflicts with zero trust, which assumes no implicit trust in a device or network location. NIST’s NIST SP 800-207 Zero Trust Architecture makes that posture explicit: identity and context must be evaluated continuously, not inherited from an endpoint that may already be compromised.

For digital trust workflows, signing keys are not just secrets. They are the cryptographic root of non-repudiation, authorization, and auditability. If a key lives on an endpoint, the organisation is depending on local hardening, patching, and user behaviour to preserve the trust boundary. That is a weak model for certificate signing, software signing, API assertions, or agent-to-agent trust. NHIMG’s Ultimate Guide to NHIs notes that 79% of organisations have experienced secrets leaks, and 77% of those incidents caused tangible damage. In practice, many security teams discover endpoint signing failure only after a key has been copied, reused, or signed artifacts have already propagated downstream.

How It Works in Practice

The practical alternative is to remove long-lived signing keys from endpoints and place signing authority in a controlled cryptographic environment, such as an HSM, remote signing service, or tightly governed workload identity platform. The endpoint should authenticate the request, but it should not hold the durable private key. This preserves Zero Trust because the device no longer becomes the trust anchor; the policy decision moves to runtime controls, key custody, and short-lived authorization.

In a stronger model, the workload proves what it is using workload identity, then receives permission to sign only for a specific action, time window, and policy context. That aligns with the direction described in the Guide to SPIFFE and SPIRE, where cryptographic workload identity replaces endpoint-held assumptions. Current guidance suggests combining this with short-lived credentials, role separation, and signed audit trails so revocation is effective and misuse is detectable.

• Use remote signing or HSM-backed signing instead of private keys on laptops, runners, or application hosts.
• Bind signing approvals to workload identity, request context, and policy-as-code rather than static device trust.
• Rotate keys on a short schedule and revoke them automatically when a workload, pipeline, or agent changes state.
• Log every signing event with the workload identity, policy decision, and artifact hash for later verification.

For regulated environments, pair this design with control expectations from NIST SP 800-53 Rev 5 Security and Privacy Controls, especially around access enforcement, auditability, and cryptographic protection. These controls tend to break down in CI/CD systems that cache credentials on ephemeral build agents because the signing key is often copied faster than revocation can spread.

Common Variations and Edge Cases

Tighter signing controls often increase operational overhead, requiring organisations to balance cryptographic assurance against release speed and developer friction. There is no universal standard for every digital trust workflow yet, so the right design depends on whether the signer is a human operator, a service account, or an autonomous workflow.

Some teams keep endpoint-based signing for low-risk internal use cases, but that should be treated as an exception, not the default. Best practice is evolving toward centralised key custody, just-in-time signing rights, and continuous validation of the request source. This becomes especially important when signing happens inside CI/CD pipelines, ephemeral containers, or AI-driven automation that can chain actions unpredictably. NHIMG’s research on the GitHub Action tj-actions Supply Chain Attack shows how quickly secrets can be exposed once automation is trusted too broadly.

Endpoint-based signing also becomes weaker when devices are shared, unmanaged, or intermittently connected to corporate controls. In those conditions, revocation and non-repudiation are delayed by design, which undermines the whole point of digital trust. NHIMG’s Ultimate Guide to NHIs -- Standards is the more reliable reference point for aligning signing workflows to governance, custody, and lifecycle control.

Related resources from NHI Mgmt Group

• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?
• Why do NHIs complicate zero trust and least privilege efforts?
• What is the difference between zero trust for users and zero trust for NHIs?