Architecture and operating model
Secure Boot validates trusted signatures for bootloaders and drivers during UEFI startup. A vTPM provides virtual TPM 2.0 functions for key storage and measured boot. They are distinct controls: Secure Boot constrains the permitted code chain, while vTPM supplies measurements and key-binding capabilities.
On many platforms, vTPM depends on VM encryption or a separate key provider. Copying VM files may therefore fail to preserve vTPM identity or disk-encryption keys. Cloning, snapshots, backup, live migration and movement between clusters must be tested against the actual platform release.
The trust chain includes physical host firmware, hypervisor, key provider, management plane and guest. Adding vTPM does not attest the host by itself; it gives the guest a virtual trust root. Recovery keys stored only behind the same vTPM or KMS can make a host or key-service loss unrecoverable.
- 1UEFI firmware
- 2Secure Boot validation
- 3vTPM measurements and keys
- 4Guest operating system
Design parameters
- Firmware mode
- Choose UEFI/Generation 2 for new VMs; create backup and rollback plans before converting legacy BIOS workloads.
- Key provider
- Design KMS or platform key-service resilience, permissions and audit independently from the VM.
- Portability
- Verify whether vTPM identity is copied or replaced during clone and migration on the target platform.
- Recovery
- Keep disk-encryption recovery material accessible independently of vTPM loss, protected by dual control and audit.
Worked example
Enable Generation 2, Secure Boot and vTPM for a Windows Server pilot, then enable disk encryption only after external recovery material exists. Reboot on the same host, live-migrate to another node and restore into an isolated network, recording boot and key-unseal results at every stage.
For 100 VMs, use waves by operating-system and application group. Do not proceed until each wave passes migration, backup restore and key-provider outage tests.
Example commands: replace lab values and confirm permissions and software versions before use.
# Windows guest examples
Confirm-SecureBootUEFI
Get-Tpm
manage-bde -status
# Linux guest examples
bootctl status
dmesg | grep -i -E 'secure boot|tpm'Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| VM fails after enabling Secure Boot | Bootloader, driver or template signature may not match the trusted database. | Inspect console events and firmware template selection before disabling protection. |
| Migration is blocked by vTPM | Target cluster may lack compatible key-provider or virtual-hardware support. | Compare source/target compatibility, key-provider access and VM hardware version. |
| Restored guest asks for recovery | vTPM measurement or identity differs from the previous state. | Use controlled recovery material and audit the measurement change; never release keys to an unverified VM. |
Acceptance checks
- Confirm unsigned boot media is blocked as intended.
- Verify TPM 2.0 visibility inside the guest.
- Test live migration and cold movement separately.
- Exercise recovery material during isolated restore.
- Measure key-provider outage effects on running and new VMs.
- Document copy-versus-replace behavior for cloned vTPMs.
Related concepts
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new accesses are denied when the identity provider becomes unavailable.
Encryption and key lifecycle
Encryption makes data difficult to read without its key; access control, deletion protection and backup address different needs. Identify which layer protects data in transit and data at rest. Key generation, protection, rotation and emergency recovery are part of the design. A key needed to restore a backup must not exist only on the server that could be lost in the incident. Test decryption and key-access recovery using a separate administrator in a lab, and keep real keys out of documentation and support messages.
Dependencies and restart order
Services commonly depend on identity, DNS, time, networking, databases and licensing. Record a dependency graph describing conditions for operation, not merely an equipment list. Recovery order follows that graph; circular dependencies may require emergency access paths. Distinguish restored infrastructure from resumed business activity. Assign an owner, validation method and alternative access path to each dependency. Test assumptions by deliberately making one component unavailable in a controlled end-to-end exercise.
Availability versus recovery
High availability aims to keep service running through specified failures with a short interruption; backup recovers lost or corrupted data from an earlier point. A cluster can replicate an accidental deletion to another node. HA therefore does not replace backup. Consider DNS, identity, network, storage and power dependencies together. Successful node failover is insufficient by itself: measure user sessions, application writes and external integrations after the transition as well.
Version and support lifecycle
Installability does not prove production support. Review the compatibility chain across OS, application, drivers, extensions and management tools. Update plans should record version, support end, restart needs and rollback methods. An unrepresentative test environment can produce misleading results. Validate service health and existing workflows after a change, not just version numbers. Remember that pinning a version can also prevent future security fixes.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.