AMD SEV and Intel TDX: who needs it

Conventional virtualization has long been the baseline way to isolate workloads, but it has a fundamental limitation: the guest still largely depends on trust in the host, the hypervisor, and the platform’s administrative control plane. In a private cluster, that is often acceptable. In a public cloud, hosted private cloud, and multi-tenant infrastructure, not always. This is exactly the backdrop against which interest in confidential computing grew: a model where data must be protected not only at rest and in transit, but also in use, meaning while it is being processed inside a virtual machine. Microsoft explicitly describes a confidential VM as a hardware-protected boundary between the application and the virtualization layer, and in the IaaS model it treats AMD SEV-SNP and Intel TDX as VM isolation mechanisms for such scenarios.

It is important to define the boundaries right away. AMD SEV-SNP and Intel TDX do not make a system “invulnerable,” do not replace guest OS hardening, and do not eliminate the need for access control, segmentation, secret management, and auditing. Their purpose is more practical: to reduce trust in the platform as part of the trusted computing base and to make access to guest memory and state from the host or hypervisor much harder. This is especially valuable where the infrastructure does not belong to you, where the data is sensitive, and where the threat model includes privileged administrators, the cloud operator, or the compromise of part of the platform stack.

Why conventional virtualization is no longer always enough

Classic VM isolation works well as long as the customer is willing to trust the provider, the hypervisor, and the host management tools. But in modern cloud models, that trust is increasingly becoming a non-obvious assumption. A SaaS provider may store customers’ personal data in a public cloud, a contractor may run someone else’s code in its infrastructure, and an enterprise customer may require that even the platform operator not have full access to the data while it is being processed. In that framing, the question is no longer limited to disk encryption and TLS between services.

That is the logic behind confidential VMs. If encryption at rest protects data on storage and encryption in transit protects data during transmission, then confidential computing aims to protect it in RAM and during execution. This does not remove the need to distrust the platform as a whole, but it significantly narrows the trusted computing base and raises the difficulty of attacks from components that were previously seen as almost all-powerful.

That is why demand for such technologies did not emerge in abstract cryptography, but in very practical areas: public cloud for regulated workloads, multi-tenant SaaS, cross-organizational analytics, ML/AI inference on sensitive data, sovereign cloud, and managed platforms where the client needs not just to “move into the cloud,” but to get a clear model for protecting data from the cloud itself.

What AMD SEV, SEV-ES, and SEV-SNP are

It is not entirely correct to talk about “AMD SEV” as a single feature. It is a family of technologies that evolved in stages.

The original SEV introduced encryption for virtual machine memory. That was already a serious step forward compared to conventional virtualization, because guest memory stopped being simply an open resource to the host. Then SEV-ES appeared, extending protection to the guest execution state, including CPU registers and part of the guest context. But the truly important milestone for today’s confidential VM landscape was SEV-SNP. AMD specifically emphasizes that SNP adds strong memory integrity protection and mechanisms against malicious hypervisor attacks, including replay and memory remapping. That is why, in practical discussions today, it usually makes more sense to compare SEV-SNP with TDX rather than “SEV in general.”

This distinction is fundamental. Memory confidentiality alone is not enough if an attacker can silently substitute pages, replay older states, or manipulate memory mappings. That is why the conversation around confidential computing almost always comes down not only to confidentiality, but also to integrity. SEV-SNP matters precisely because it makes VM isolation substantially more complete in a model where the host may be untrusted or partially compromised.

That is also why the market focus has shifted toward SNP. In cloud and hosted infrastructure, the value comes not simply from the fact that memory is encrypted, but from the ability to build a stronger guarantee: the guest VM is protected not only from passive reading, but is also better able to resist certain active manipulations from the platform side. For the customer, this is no longer a decorative security feature, but an argument for a specific class of workload placement.

What Intel TDX is

Intel Trust Domain Extensions addresses the same business problem — reducing trust in the host and hypervisor when running VMs — but does so through its own architectural model. Intel describes TDX as a mechanism that provides confidentiality, integrity, and authenticity for data inside a trust domain, using hardware isolation, memory encryption, and remote attestation. Put simply, TDX creates a stricter hardware-supported boundary for the virtual machine inside which the workload runs.

In meaning, TDX is close to what SEV-SNP does: both technologies are intended for confidential VMs, both reduce the role of the hypervisor as a fully trusted element, and both matter where cryptographically strengthened guest isolation is required. But this is not “the same SEV, just from Intel.” Intel has a different architectural path, its own ecosystem, its own limitations, its own attestation process, and its own set of operational nuances.

That is why the debate over “which is better — AMD or Intel” is almost always incorrect when detached from the platform context. For an engineer, other things matter much more: how mature the implementation is at the required provider, which guest OSes are supported, how attestation and lifecycle operations work, and whether there are restrictions on snapshots, migration, debugging, security agents, and observability.

What confidential VMs actually protect — and what they do not

The most common mistake is to assign far too broad a meaning to confidential VMs. SEV-SNP and TDX do in fact protect a virtual machine’s memory from being read by the host, help isolate the workload in an environment where the hypervisor is not considered fully trusted, and provide the basis for verifying trusted state through attestation. Depending on the technology and configuration, they also affect the protection of part of the execution state and integrity. That makes them especially useful for tenant isolation in the cloud and for sensitive VMs that cannot simply be left to the discretion of the platform administrator.

But protection does not end there — and magic does not begin. If the application inside the guest is vulnerable, a confidential VM will not save it. If an attacker gets root access inside the VM itself, the TEE does not turn the compromised system back into a trusted one. If you have a weak IAM model, poor secret management, gaps in CI/CD, unverified images, insecure monitoring agents, or chaos in network segmentation, SEV-SNP and TDX will not solve those problems.

Side-channel risks also deserve separate mention. Neither AMD nor Intel positions these technologies as a universal solution for all side channels. What is being offered is a reduction of the trusted base and hardware isolation against a certain class of attacks, not a complete closure of the entire attack surface. That is why confidential VMs should be seen as one layer in an overall architecture, not as a replacement for basic security hygiene.

This is exactly where the line runs between a “useful technology” and a “security checkbox.” If an organization cannot maintain images, patch the OS, manage keys, logging, and access properly, confidential computing will not fix fundamental operational failures.

Who really needs AMD SEV and Intel TDX

Public cloud and multi-tenant infrastructure

This is the most obvious and mature scenario. When a workload lives in the public cloud, you do not control the physical server, the firmware stack, the hypervisor, or the provider’s administrative plane. Even if you trust the provider in general, you may still need to reduce how much you trust it. This is exactly where confidential VMs deliver their clearest value.

First and foremost, this is relevant for processing PII, financial data, medical information, customer data in multi-tenant SaaS, and B2B services where the customer asks not only about disk encryption, but also about protection during execution. In such discussions, SEV-SNP or TDX is not a universal answer, but it is already a concrete argument for the security review, the compliance team, and enterprise procurement.

Hosted private cloud and service provider infrastructure

Managed hosting, MSPs, and sovereign cloud have a similar logic, only the level of control is usually higher and customer requirements are more varied. Here, a confidential VM can become an additional security tier: not just “we isolate projects with hypervisor mechanisms,” but “we reduce trust in the platform at the hardware level.”

But real value appears only when the provider can explain the operational model. Is attestation available? How is image support handled? What about observability? What limitations exist for live migration, snapshots, and debugging? Until there are answers to these questions, a confidential VM remains a nice feature in a presentation, not a mature service.

Regulated workloads and sensitive data

In highly regulated environments, confidential VMs matter not because they automatically ensure compliance, but because they strengthen the protection architecture. They help address part of the questions around data in use and provide a stronger isolation model than conventional virtualization.

This is especially visible in healthcare, fintech, government and near-government scenarios, as well as in international B2B models where one side wants to run code or store data in the other side’s infrastructure, but is not willing to trust the entire platform stack unconditionally.

Cross-organizational computing and confidential workloads

A separate class of use cases includes joint analytics across several organizations, confidential data sharing, clean rooms, inference on sensitive datasets, and running proprietary models outside a fully controlled perimeter.

Neither SEV-SNP nor TDX solves everything by itself, but both provide an important foundation. Especially if a workflow is built on top of them that includes attestation, a policy engine, and secret release only to a trusted workload instance.

Who most likely does not need these technologies

Not every VM needs confidential computing. If you run standard corporate systems without particularly sensitive data, dev/test environments, short-lived ephemeral workloads, or small business infrastructure without a distinct threat model involving the platform side, the benefit may be minimal.

The same is true for teams that do not have maturity in attestation, image trust, and configuration control. If an organization has not yet learned to keep the basics in order, confidential VMs often become not a security improvement, but an expensive complication.

How to tell whether you need them

The right question is not “does our provider support confidential VMs,” but “do we have a threat model that makes them justified.” To answer that, it is worth going through a set of questions in sequence:

How much do you trust the cloud operator or hosting provider?

How significant is the risk of access by privileged platform administrators?

Do your customer, partner, or regulator require protection for data in the use state?

Do you need remote verification of the instance’s trusted state before issuing keys and secrets?

Do you store or process genuinely sensitive data?

Are you ready to accept restrictions in compatibility, migration, observability, and support?

Can you use attestation as part of a real workflow rather than as a formal checkbox?

Practical scenario guide

If this analysis shows that your main risk is not an untrusted host at all, but weak IAM, messy secret handling, or lack of patch management, then you should not start with SEV-SNP or TDX.

AMD SEV-SNP vs Intel TDX: how to compare them without oversimplifying

There is no point in comparing these technologies only through neat diagrams. For practical selection, very different things matter: where they are available, how mature they are at specific cloud providers, which configurations are supported, how convenient attestation is, what happens with live migration, snapshots, debugging, and observability, and how performance changes for a specific workload type.

As of today, AMD has historically been more visible in the confidential VM space as a more mature and longer-discussed option for cloud scenarios, especially in the context of SEV-SNP. Intel TDX is rapidly catching up and becoming increasingly attractive where an organization is already building around the Xeon ecosystem or choosing a cloud where TDX is offered as a fully supported option. Microsoft notes that Azure offers TEE-based options on both AMD and Intel, while Google Cloud describes Confidential VM support for both AMD SEV/SEV-SNP and Intel TDX.

This means something simple: for many teams, the choice is not between “AMD philosophy” and “Intel philosophy,” but between specific VM types, regions, CPU platforms, and the provider’s support matrix. If the cloud you need has had SEV-SNP available for a long time, supports the required images, and fits well into your lifecycle, that is a strong argument. If, on the other hand, your stack is tightly linked to the Intel platform and TDX is implemented in a mature way by your chosen provider, the practical balance may shift in that direction.

Comparison by key criteria

Limitations and hidden trade-offs

The most underestimated part of the topic is operations. Confidential VMs are almost never introduced without side effects. Not all guest OSes and not all image types are supported equally well. Low-level debugging tools, introspection, and some security agents may work differently or require adaptation. Live migration, snapshots, device passthrough, and other familiar operations can sometimes be limited or behave differently than they do in ordinary VMs.

In addition, attestation by itself does very little if it is not embedded into the workload lifecycle. If secrets are still issued to an instance without verifying trust claims, much of the value is lost. If observability requires agents with deep access to the system, the confidential VM model may conflict with established monitoring practices. If the team cannot maintain firmware, microcode, the guest kernel, and security advisories, operational complexity quickly starts to outweigh architectural elegance. In Intel’s TDX documentation, both secure development and attestation, as well as enablement and operational guidance, are highlighted explicitly, which in itself shows something important: this is not a “one-click option,” but an additional layer of engineering discipline.

Another practical factor is performance. It may be close to a normal VM for some workloads, while for others it may change depending on the profile: CPU-heavy, memory-heavy, I/O-heavy, and workloads involving agents and observability stacks. That is why any promise that “the overhead is negligible” needs to be validated on your actual workload, not on a marketing example.

Why attestation matters no less than isolation itself

Without attestation, a confidential VM remains an incomplete construct. Yes, the guest’s memory is better protected, and yes, the trusted base is reduced, but an external system still needs to understand that the workload really started in the expected and acceptable configuration.

That is the purpose of attestation: to obtain confirmation that the instance is running inside the required trusted environment, with the expected configuration, on an acceptable platform, and without deviations critical to your access policy. On Google Cloud, attestation is explicitly described as a way to increase confidence that a Confidential VM is legitimate and running in the expected state.

In practice, it looks like this. The workload starts, obtains attestation evidence, passes it to an external verifier or KMS, and that system then decides whether to release a key, token, access to data, or access to a confidential model. It is exactly the combination of TEE + attestation + policy that turns a platform feature into a working security pattern. Without it, a confidential VM too often remains simply a better-protected VM that is still weakly integrated into the trust workflow.

That is why mature implementations begin not with the question “do we have SNP or TDX,” but with the question “what exactly are we going to do with attestation, and how does it influence secret release and trust in the workload.”

Where this is already being used in practice

The topic has long moved beyond laboratory concepts. Azure directly offers confidential VMs as an IaaS model for scenarios with heightened confidentiality requirements and supports TEE options on both AMD and Intel. Google Cloud also supports Confidential VM based on AMD SEV, SEV-SNP, and Intel TDX. At the same time, both platforms emphasize an important market advantage: in some cases, a workload can be moved to a confidential VM without deep application redesign, that is, in a mode close to lift-and-shift.

This is an important distinction from enclave models, where extracting real value often requires more substantial application adaptation. Confidential VMs are valuable precisely because they provide hardware-strengthened isolation at the virtual machine level rather than requiring the entire architecture to be rebuilt around enclave APIs from the outset.

Practical conclusion: adopt, test, or leave it alone

If reduced to the essence, AMD SEV-SNP and Intel TDX are needed by those who work with sensitive data in a virtualized environment and do not want to fully trust the host, the hypervisor, or the platform operator. First and foremost, that includes public cloud, hosted multi-tenant environments, regulated workloads, cross-organizational computing, and scenarios where secrets and access to data are released only after the workload’s trusted state has been verified.

If, however, your main problems lie in IAM, backups, patch management, image control, and basic operational discipline, confidential VMs will not be the best first investment. They do not replace security hygiene and do not compensate for weak operations.

When does it make more sense to look toward AMD SEV-SNP?

When you need a more mature practical story for confidential VMs, when current cloud availability matters, and when you are oriented toward the EPYC platform or AMD-based cloud offerings.

When does it make sense to consider Intel TDX?

When your infrastructure strategy is tied to the Xeon ecosystem, your chosen provider already delivers mature TDX support, and you are evaluating not an abstract feature but a concrete platform implementation.

In many cases, the right answer will be somewhere in between: not “deploy immediately everywhere,” but test selectively. For one workload class — for example PII in a public cloud, inference on a proprietary model, or managed hosting for an enterprise customer — it may be truly justified. For the rest of the VMs, it may remain unnecessary complexity.

That is why the main selection criterion is not the CPU brand and not the trendiness of confidential computing. You should choose based on the threat model, the maturity of attestation processes, platform compatibility, and whether the technology provides a real operational fit for your specific infrastructure.