SEV-SNP: what evidence supports accepting a host?

Two bulletins with distinct conditions and schedules

AMD-SB-3059 describes CVE-2026-0462: a malicious hypervisor may compromise SEV-SNP integrity through MMIO redirection. AMD-SB-3061 covers CVE-2026-40671 and possible exposure of SEV-SNP guest registers to a privileged attacker.

For the server EPYC series in the main table, the first bulletin records August SEV firmware and PI versions planned for December; the second records August microcode and PI planned for November. AMD directs customers to the equipment manufacturer for the applicable BIOS. These are vulnerability disclosures, without evidence of a specific incident in those descriptions.

Define the question the operator must answer

Ask for a link between the workload, its permitted host pool and the required version of each relevant component. A commercial statement about a service family must connect to the contracted environment. With a managed infrastructure provider, agree which identifiers can be shared and which record demonstrates that the change was applied.

Write the acceptance condition before the window. It might require the model, installed version, manufacturer reference, application timestamp and operator validation result. Assign an owner and a response date to missing information. Avoid closing the ticket solely on an expected delivery date for an update.

Separate publication, application and workload authorization

Keep three fields in the record: applicable update, observed application and workload decision. Each needs its own evidence. The first points to the manufacturer’s reference; the second identifies the changed environment; the third records who accepted the result for its intended use and which conditions remain.

Plan continuity with the application owner. Record how participants will recognize the authorized host or group after maintenance, which checks they will perform and which discrepancy will prevent resumption. The earlier analysis of AMD Turin and maintenance inside a VM complements the discussion but covers different bulletins and cannot replace this assessment.

Carry acceptance into the admission policy

If the architecture uses attestation to release a workload, ask its owner to show how the policy accepts or rejects the evidence received. Use an authorized scenario with synthetic values to test one permitted condition and one rejected condition. Preserve the policy version, outcome and test identifier without publishing sensitive workload material.

The proposal is to examine the decision without developing a vulnerability exploit. A documented policy and an observable test support discussion of whether a contracted requirement is being enforced. Any coverage statement should identify the platforms examined and the dependencies outside the exercise.

Close with an owner for each outstanding item

Create an environment record with an accountable owner, available evidence, expected result and next decision. Separate accepted maintenance from items awaiting manufacturer or provider information. Schedule a review after a change in host, policy or service requirement. Acceptance must remain retrievable when the workload moves.

The analysis of nested virtualization and the host boundary helps frame responsibilities between layers. For this case, preserve the link between current bulletins and the assets actually assessed. A processor name alone does not describe the environment or the decision made.

Frequently asked questions

Related reading

• AMD Turin: maintenance observed inside the VM
• Responsibilities between virtualization layers

Sources and references

• AMD-SB-3059, November 10, 2026
• AMD-SB-3061, November 10, 2026

Original Pentesty analysis, published November 13, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.