Attest a Confidential VM

Attestation cryptographically proves that your Confidential VM is running an unmodified software stack on genuine AMD SEV-SNP hardware, with the expected security policy active. This topic explains how attestation works, when to use it, and how to set it up using either the IONOS CLOUD open-source reference toolchain (Example: SNPGuard) or your own attestation service. It also covers re-attestation after software updates and the connectivity requirements your attestation service must meet.

Prerequisites:

• Your Confidential VM image is prepared.
• Access to either SNPGuard or your own attestation service implementation.
• Network connectivity planned from the VM to your attestation service.

How Confidential VM attestation works

1

Understand how attestation works

Attestation is the mechanism by which a Confidential VM proves to your key server that it is running an unmodified software stack on genuine AMD hardware within a Trusted Execution Environment (TEE). The proof requires no trust in the network, the host, or IONOS CLOUD.

The protocol runs entirely within the initrd, before the operating system mounts the root filesystem. If the proof succeeds, the attestation service releases the Volume Master Key (VMK) and the VM boots. If anything in the startup chain has been tampered with or if the hardware cannot be verified, the proof fails and the VM halts.

1. At every VM start, the AMD hardware generates a signed report containing:

• A measurement (SHA-384 hash) of the firmware, kernel, initrd, and kernel command line.
• The CPU security policy in effect
• The AMD hardware version

2. Your attestation service receives this report, checks it against your registered expected values, and (if everything matches) releases your Volume Master Key, which unlocks the LUKS root filesystem. If the check fails, the key is not released and the VM does not start into a trusted state.

Note:

• You do not need attestation to run a Confidential VM: Your VM starts, your encrypted disk becomes available, and your workload runs without an attestation service.
• Use attestation for verification: Cryptographically prove that your VM runs exactly the software stack you built, on real AMD hardware, with the expected security policy active. If you need that guarantee (for compliance, key release policies, or your own trust model), deploy an attestation service.

2

Understand why external verification is needed

In a zero-trust setting, encrypting RAM is not enough; you must also prove that the VM's startup process was not tampered with before it started. Software running within the VM cannot provide this proof on its own, as it is part of what needs to be verified.

1. The AMD hardware generates a signed attestation report from within the VM, one that cannot be forged by software.

2. An external service you control then validates that report before releasing any secrets. IONOS CLOUD cannot operate this service on your behalf; if it did, it holds the key release decision, undermining the zero-trust model entirely.

3. The CPU generates a signed attestation report containing the launch measurement.

4. Your attestation service checks the following requirements:

• Is the attestation report signed by a genuine AMD CPU?
• Does the measurement match the expectation?

Only if both hold does it release the key that unlocks the disk.

3

Plan connectivity requirements

Your attestation service must be reachable from the VM's network during the initrd launch phase, before any VPN or overlay network is established. Plan and validate this connectivity at image build time. If the attestation service is unreachable at startup, the VM cannot obtain the key and will not complete startup.

4

Choose your attestation toolchain

SNPGuard IONOS CLOUD reference toolchain

SNPGuard is the IONOS CLOUD open-source reference implementation. It provides:

• An attestation client that runs within the VM's initrd at VMPL0 (the highest hardware privilege level, required for valid attestation reports).
• A reference attestation service implementation.
• Image preparation tooling that automates LUKS encryption, client injection, measurement registration, and artifact embedding.

For more information, refer to the following:

• Repository
• README
• Architecture

Own or partner tooling

If you have an existing attestation service or prefer a commercial solution (for example, from an ISV partner), you can integrate directly with the AMD SEV-SNP attestation protocol. Your attestation client must:

• Run at VMPL0 within the initrd, before the OS mounts the root filesystem.
• Request an attestation report from the AMD hardware.
• Send the report to your attestation service for verification.

For more information, refer to the AMD SEV-SNP Attestation specification.

5

Understand re-attestation

If you update the kernel or initrd within a running VM, the measurement changes. The attestation service will reject the old measurement on the next start. You have two options:

1. Register the new measurement with your attestation service before rebooting. This is the standard update path.
2. Re-attest from within the running VM: SNPGuard provides an attest renew flow: the already-trusted VM submits its updated artifacts to the service, which registers them for the next start. This avoids a full rebuild-and-reupload cycle.

Important: Restarting a Confidential VM initiates a full stop-and-start rather than an in-place restart. For more information, see Limitations. The attestation flow runs fresh on every start.

Result: Your Confidential VM attestation setup is complete. Your attestation service can now verify VM integrity and release keys on demand.