Independent trust validation for confidential computing is maturing

At a glance

What this is: DigiCert and Google Cloud are extending PKI-based trust validation into confidential computing so organisations can independently verify cloud workloads and infrastructure integrity.

Why it matters: This matters because identity teams now have to govern trust for machine and workload identities in environments where provider assurance is no longer enough.

By the numbers:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
• 59% of organisations face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility.
• 69% of organisations now have more machine identities than human ones.

👉 Read DigiCert's press release on independent trust validation for confidential computing

Context

Confidential computing reduces exposure while data is in use, but it does not remove the governance problem of proving that a workload is authentic and untampered. For identity teams, the issue is not just encryption or enclave isolation. It is whether the organisation can independently attest to the integrity of the workload, the host environment, and the trust chain behind both.

That distinction matters for NHI governance because cloud workloads, certificates, and cryptographic attestations are identity constructs, not just infrastructure features. When sensitive applications, AI workloads, and regulated processing move into confidential environments, the control question becomes who or what is trusted, under what evidence, and with what lifecycle oversight.

Key questions

Q: How should security teams govern trust for confidential computing workloads?

A: Security teams should treat confidential computing trust as a workload identity issue, not only an infrastructure issue. That means assigning ownership, requiring independent attestation evidence, and binding trust decisions to certificate lifecycle, revocation, and auditability. If a workload cannot prove its identity and integrity, it should not be trusted just because it runs inside a protected environment.

Q: Why do confidential computing environments still need independent verification?

A: Because isolation protects data in use, but it does not automatically prove that the workload or environment is authentic. Independent verification gives security teams evidence they can audit outside the cloud provider's own assurance model. That matters most for regulated, cross-domain, or high-value processing where trust must be demonstrable, not assumed.

Q: What breaks when attestation certificates are not managed like identities?

A: The attestation model loses operational value if issuance, renewal, expiry, and revocation are handled ad hoc. In practice, you end up with cryptographic proof that cannot be trusted at the moment it is needed. That creates a governance gap where the control exists on paper but fails in real workflows.

Q: When should organisations require an external root of trust for cloud workloads?

A: Organisations should require an external root of trust when provider assurances are not enough for audit, segregation, or regulatory confidence. The clearest cases are sensitive workloads, shared cloud environments, and AI processing where independent evidence of integrity matters. The decision should be based on risk and evidence requirements, not on convenience.

How it works in practice

Independent attestation in confidential computing

Confidential computing protects data while it is being processed by isolating workloads in hardware-backed environments, but isolation alone does not prove identity or integrity. Independent attestation adds a separate trust signal: cryptographic evidence that a workload, runtime, or environment matches expected state. In PKI terms, that evidence is anchored in certificates, signatures, and a trusted root that can validate claims without relying only on the platform operator. The architecture is about separating assertion from verification. That matters when the workload itself is part of the control plane for sensitive processing.

Practical implication: identity teams should treat attestation evidence as part of workload governance, not as a substitute for access control or lifecycle management.

PKI as a trust layer for cloud workloads

PKI provides binding between an identity and a verifiable cryptographic credential, which is why it remains relevant when cloud infrastructure needs independent proof. In this model, certificates and signing chains let organisations verify that a workload is what it claims to be and that its environment has not been modified. The important point is that the trust object is not a person. It is a machine identity or workload identity whose authenticity must be validated continuously across cloud boundaries. That is a different governance problem from user authentication, even if the same cryptographic primitives appear underneath.

Practical implication: map workload identities to certificate lifecycle, attestation policy, and revocation workflows instead of treating them as static infrastructure artifacts.

Why provider attestation is not the whole control

Cloud provider attestation proves something about the platform's own trust model, but it does not always satisfy an organisation that needs independent verification for regulated data or cross-domain workloads. A third-party trust root changes the evidence model by giving security teams a separate point of assurance. That reduces reliance on a single operator's claims and creates a more auditable chain for environments where the workload, the control plane, and the consuming business process all carry different risk. This is especially relevant as AI and high-value workloads become more dynamic and distributed.

Practical implication: decide where provider attestation is sufficient and where an external root of trust is required for auditability, segregation, or regulatory confidence.

NHI Mgmt Group analysis

Independent trust validation is becoming a workload identity problem, not just a cloud assurance problem. Once sensitive processing moves into confidential computing, the organisation has to prove that the workload, the enclave, and the trust chain are genuine. That shifts the control discussion from provider confidence to evidence-based identity governance. The practitioner implication is that machine trust now needs lifecycle and verification discipline, not only infrastructure hardening.

Certificate lifecycle is the weak point that determines whether attestation is usable at scale. A cryptographic root of trust is only useful if issuance, rotation, revocation, and expiry are managed cleanly across environments. Without that discipline, independent verification becomes an administrative claim rather than an operational control. The practitioner implication is to treat attestation certificates like high-value machine identities with formal ownership and revocation paths.

Common root of trust is the right concept, but it increases the need for explicit trust boundaries. Distributed cloud and AI workloads often span teams, environments, and compliance scopes, so a shared trust model can improve consistency while also making failures more consequential. If the trust root is poorly governed, the blast radius is structural. The practitioner implication is to define where one attestation domain ends and another begins before workloads start depending on it.

Confidential computing exposes an identity assumption that has been too implicit for too long. Traditional cloud governance was designed for environments where the platform operator's assurances were accepted as the baseline. That assumption fails when organisations need independent proof of integrity for sensitive or regulated processing because the actor being trusted is the workload itself, not a human approver. The implication is that security teams must rethink how they establish trust in machine-mediated execution.

Verifiable trust architectures are now part of the NHI governance surface. As AI workloads and regulated systems migrate into enclaves, the identity story shifts from authentication at the edge to evidence inside the runtime. That broadens NHI governance from secret control to proof control. The practitioner implication is that workload identity, attestation, and certificate governance now need to be managed as one control family.

From our research:

• Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to the 2026 Infrastructure Identity Survey.
• A separate finding from The Critical Gaps in Machine Identity Management report shows that 57% of organisations lack a complete inventory of their machine identities, which weakens any attempt to validate trust consistently.
• For the broader governance pattern, see Ultimate Guide to NHIs , Standards for how identity controls, zero trust, and workload identity standards fit together.

What this signals

Independent attestation will increasingly sit inside the IAM programme, not beside it. As cloud trust moves from provider assurance to verifiable evidence, teams will need a control model that covers machine identities, certificates, and runtime trust decisions together. With 69% of security leaders already saying identity management must fundamentally shift for agentic AI, the direction of travel is toward governance that can prove identity at execution time, not just at enrollment.

Certificate-backed workload trust creates a new operational dependency for platform teams. If attestation becomes the decision point for sensitive workload access, then certificate expiry, revocation, and ownership gaps become direct availability and assurance risks. That is especially relevant where the workload is also feeding AI systems or regulated processing pipelines.

Common root of trust: this is the concept practitioners should watch closely because it can simplify assurance across distributed environments while also concentrating failure if governance is weak. For teams already struggling with inventory and ownership, the question is whether they can sustain the evidence chain at cloud speed.

For practitioners

• Map attestation to workload identity ownership Assign a named owner for every confidential workload that depends on attestation evidence, and require that owner to manage certificate issuance, rotation, and revocation as part of the workload lifecycle.
• Define where provider assurance stops Document which processing flows can rely on cloud provider attestation and which require an independent trust root because of regulatory scope, data sensitivity, or cross-domain dependency.
• Integrate attestation into access decisions Require runtime trust evidence before allowing sensitive workloads to connect to downstream data, APIs, or orchestration services, especially where machine identity is the primary actor.
• Govern certificate lifecycle as a control plane Track certificates used for workload verification with the same discipline you apply to privileged machine credentials, including expiry monitoring, revocation testing, and ownership reviews.

Key takeaways

• Confidential computing does not solve trust on its own. It shifts the problem to whether workloads, environments, and identities can be independently verified.
• Certificate lifecycle now sits at the centre of workload assurance, because attestation only works when issuance, rotation, and revocation are governed well.
• Security teams should decide where provider attestation is sufficient and where an external root of trust is required for sensitive, regulated, or cross-domain workloads.

Key terms

• Independent Attestation: Independent attestation is cryptographic proof that a workload or computing environment matches an expected state. It separates verification from the platform operator's own claims, which is useful when organisations need auditable evidence of integrity for sensitive processing, regulated workloads, or machine-mediated trust decisions.
• Confidential Computing: Confidential computing is a hardware-backed processing model that protects data while it is in use by isolating workloads from broader system access. It reduces exposure, but it does not by itself prove identity or integrity, so governance still needs attestation, certificate control, and trust-boundary management.
• Workload Identity: Workload identity is the machine identity assigned to an application, service, or runtime so it can be authenticated and authorised in a cloud or distributed environment. In confidential computing, workload identity must be tied to proof that the runtime is genuine, not only to a static credential or name.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by DigiCert: Independent trust validation with Google Cloud for confidential computing. Read the original.