Treat missing kernel evidence as a trust failure, not a partial success. If the process cannot be tied to immutable runtime facts such as executable hash, namespace, and start time, do not mint the same credential class that a fully attested workload would receive. The decision should fail closed until the evidence set is complete and verifiable.
When should incomplete runtime evidence stop a credential from being issued?
runtime evidence is only useful when it lets you distinguish a specific live workload from a merely plausible one. If the attestation set is missing core facts, such as an immutable executable hash, namespace binding, or trustworthy start time, the safer decision is to delay issuance. That keeps the credential boundary aligned to verified runtime state rather than assumptions.
Why incomplete evidence changes the credentialing decision
Partial evidence creates a false sense of certainty. A process that cannot be tied to stable runtime facts may be moved, replayed, replaced, or impersonated, which means the credential would no longer be scoped to the entity you think it is. In practice, that weakens trust in the credential issuer and blurs the line between proof and preference.
For workload identity, the point of evidence is not to prove that something is running somewhere, but to prove which workload instance is running under which conditions. That is why attestation should be treated as a gating control, not a nice-to-have signal. SPIFFE workload identity specification is a useful reference for the attestation model behind that decision.
When teams skip that gate, they usually create one of two failures: they either issue a credential too broadly, or they issue the right credential to the wrong runtime. Both outcomes increase blast radius, because the credential becomes usable outside the trust conditions that were supposed to constrain it.
What good issuance looks like when attestation is incomplete
Good practice is to separate workload identity from convenience-based access. If the evidence set is incomplete, the workflow should fail closed, surface exactly which proof elements are missing, and require a retry or remediation path rather than silently downgrading assurance. That keeps the policy decision understandable and auditable.
Teams should also define a narrow fallback path for exceptional cases. For example, a workload might be allowed to obtain a lower-privilege, shorter-lived bootstrap credential while the missing evidence is resolved, but only if that fallback is explicit, logged, and materially less powerful than the fully attested credential class. The safest default is still to deny the main credential until the attestation bundle is complete.
For runtime-focused platforms, container and orchestration context matter because image provenance, runtime state, and scheduler metadata can all affect whether the workload is actually the one being authenticated. NIST SP 800-190 Container Security reinforces why runtime trust cannot rest on a single weak indicator.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST SP 800-190, NIST Zero Trust (SP 800-207) and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | Incomplete attestation makes workload credential issuance unsafe. |
| NHI-06 — Insecure Cloud Deployment Configurations | Runtime evidence gaps often stem from weak deployment and attestation integration. | |
| Recommendation — Deny full credential issuance until runtime evidence is complete and verified. Bind issuance to deployment metadata and verified runtime signals before trusting the workload. | ||
| NIST SP 800-53 Rev 5 | IA-9 — Service Identification and Authentication | Workloads and services need strong identity proof before receiving credentials. |
| IA-5 — Authenticator Management | Credential minting depends on lifecycle controls when assurance is incomplete. | |
| AC-6 — Least Privilege | A fallback credential, if any, should be narrower than the fully attested one. | |
| Recommendation — Require service-to-service authentication evidence before issuing the credential. Use short-lived or withheld authenticators until evidence is sufficient. Constrain any fallback access to the minimum privilege needed for remediation. | ||
| NIST SP 800-190 | Container Security | Container runtime trust depends on image, orchestration and runtime evidence. |
| Recommendation — Use container runtime and provenance checks before granting workload credentials. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection | Fail-closed issuance preserves trust boundaries when evidence is incomplete. |
| Recommendation — Enforce a trust boundary that blocks credential issuance until attestation completes. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Workload credential flows often rely on federated token issuance and proof checks. |
| Recommendation — Validate federation assertions before minting workload tokens. | ||
Practitioner Guidance
What to verify: Require the issuer to check for a complete evidence chain before minting the credential, not just a positive signal from one collector. The minimum should include whatever immutable facts your policy treats as binding, plus a clear match between the presented runtime and the requested credential scope.
Decision rule: If the workload cannot be uniquely tied to trusted runtime facts, deny the standard credential and route the request through a remediation or re-attestation path. Do not “partially trust” the workload by issuing the same credential class with a weaker confidence label.
What practitioners underestimate: Missing evidence is often a control signal, not an operational inconvenience. Incomplete attestation frequently indicates instrumentation gaps, timing races, or tampering conditions that are themselves worth investigating before any credential is issued.
Practitioner takeaway: The credential should reflect the quality of the proof, not the urgency of the request. If runtime evidence is incomplete, treat that as an authorization boundary and wait for verifiable attestation before minting the full workload credential.
Related resources from NHI Mgmt Group
- How should security teams handle runtime workload evidence in their SIEM?
- How should teams govern workload identity when credentials are injected at runtime?
- How should security teams replace long-lived workload credentials with runtime authentication?
- What is the difference between runtime protection and NHI lifecycle management?