Security and Trust Model

IONOS CLOUD Confidential VM enforces data privacy through hardware-level cryptography rather than software-based hypervisor controls. It details the zero-trust architecture, the four-step secure startup process, key management, shared responsibilities, and the boundaries of what Confidential VM protects.

The zero-trust principle

Standard cloud environments rely on contractual assurances and internal access controls to protect VM data. These are policy-based guarantees: they depend on the provider behaving as agreed.

IONOS CLOUD Confidential VM replaces policy-based trust with a hardware-enforced cryptographic boundary. The AMD CPU architecture prevents access to VM memory, regardless of administrative privilege.

AMD SEV-SNP encrypts VM memory using keys that the AMD Secure Processor, a dedicated security microcontroller embedded in the CPU, generates and holds. These keys never leave the silicon. The hardware's design physically excludes the hypervisor, the host operating system, IONOS CLOUD administrators, and IONOS CLOUD itself from the decryption path. IONOS CLOUD has no keys, no backdoor, and no mechanism to access your VM's memory.

For more information about what IONOS CLOUD does not cover, see Security boundaries (End-users' responsibility).

Who holds the encryption keys?

IONOS CLOUD holds none of the following keys:

Key	Held by	Purpose
Memory encryption key	AMD Secure Processor (hardware)	Encrypts VM RAM in real time. The hardware generates it per VM; it never leaves the silicon.
Volume Master Key (VMK)	The user	Unlocks the LUKS-encrypted disk. Released into VM memory only after the VM's identity is verified.
Attestation signing key	AMD (VCEK/VLEK, through AMD's Key Distribution Service))	Signs the hardware attestation report so you can verify it.

What IONOS CLOUD can and cannot see

Because IONOS CLOUD holds no keys, it cannot produce decrypted data, not for support, not for an infrastructure incident, and not in response to a legal request.

IONOS CLOUD can see	IONOS CLOUD cannot see
That your VM exists (it is a resource in our API)	The contents of your VM's memory
Its allocated resources (cores, RAM)	The contents of your encrypted disk
API actions (create, start, stop, delete)	Your workload (what runs and what data it processes)

Shared responsibility model

The boundary between IONOS CLOUD and the user is hardware-enforced, not policy-based.

Responsibility	IONOS CLOUD	You (User)
Physical datacenter security; host hardware and AMD SEV-SNP enablement	✅	—
AMD SEV-SNP hardware integrity and availability	✅	—
SEV-SNP enabled and enforced hypervisor	✅	—
Cloud API server lifecycle management	✅	—
VM memory encryption (hardware)	✅	—
OVMF firmware build transparency and provenance	✅	Verify
Guest OS and kernel	—	✅
Root filesystem encryption (LUKS2)	—	✅
Additional block volume encryption	—	✅
Attestation service for hosting and operation	—	✅
Attestation service for TLS certificate management	—	✅
Encryption key management (VMK)	—	✅
Attestation policy definition and validation	—	✅
Network traffic encryption (TLS or WireGuard)	—	✅
Application security and hardening	—	✅
Image preparation, artifact building, and measurement	—	✅
initrd integrity and attestation agent	—	✅
Guest-side monitoring and diagnostics	—	✅

The user-operated security model

IONOS CLOUD Confidential VM is a user-operated product. The CPU enforces memory isolation in hardware; no IONOS CLOUD service, software, or personnel makes any security decisions.

Prerequisites: This product requires Linux kernel expertise, cryptographic literacy, and the operational maturity to run a security-critical service reliably.

What is a measurement and how is it computed?

A measurement is the cryptographic identity of your Confidential VM's software stack, a SHA-384 digest that the AMD Secure Processor computes during every VM start. It covers, in the following order:

1. OVMF firmware firmware-code.fd
2. Linux kernel vmlinuz
3. Initial ramdisk initrd.img
4. Kernel command-line parameters kernel-params.txt

The computation is deterministic, which means the same software stack always produces the same value. Any modification to any of these inputs produces a different measurement, which causes attestation to fail. The AMD Secure Processor records the measurement in a hardware-signed attestation report that your attestation service verifies at launch.

The launch process

Every Confidential VM start is a cryptographic event. The following four steps describe how a Confidential VM reaches a running, trusted OS.

1

Sealed startup

The VM starts with user-provided artifacts, including the kernel, initrd, OVMF firmware, and kernel parameters. You build these artifacts entirely yourself and embed them in the LAUNCH_ARTIFACTS partition. The host cannot mount the root filesystem, read it, or inject any configuration. The VM image is immutable after upload.

2

Crypto audit

The AMD Secure Processor computes a measurement of the VM's initial software state, then generates a signed attestation report containing the launch measurement, guest policy, and hardware identity. A key derived from AMD's root of trust signs this report, meaning neither IONOS CLOUD nor any host-side software can forge it.

3

initrd handshake (attestation path only)

When you use an attestation service, the initrd starts before the OS. Its internal attestation agent sends the hardware-signed attestation report to your attestation service over a TLS channel, using certificates you embedded at build time. IONOS CLOUD has no role in this process and cannot intercept this exchange. If you skip attestation, you still need the initrd to handle the disk unlock locally.

Note: The initrd is the trust anchor of the entire security model. A compromised initrd breaks the trust chain. You build it; IONOS CLOUD has no access to it.

4

Secure release (attestation path only)

Your attestation service verifies the report against your pre-registered policy. If all checks pass, the service releases the VMK directly into the VM's encrypted memory. The key never writes to disk and remains entirely invisible to IONOS CLOUD. Finally, the initrd decrypts the LUKS2 root filesystem, and the OS starts. For a detailed walkthrough, see Attest a Confidential VM.

Important: If any check fails, the attestation service does not release the VMK, and the VM cannot start.

Firmware transparency

Every OVMF firmware release relies on TianoCore EDK II, the open-source UEFI/firmware development framework. For each release:

• A public GitHub Actions CI pipeline builds the artifact.
• GitHub's OIDC infrastructure signs the release with SLSA Level 2 provenance.
• The Sigstore Rekor public transparency log permanently records the transaction.

IONOS CLOUD holds no private signing keys. The Rekor log is append-only; it rejects any modification or deletion of existing entries.

For verification steps, see Verify the OVMF firmware.