Intel CSME and AMD PSP Explained: Architecture, Updates, Admin Checks

Intel's Converged Security and Management Engine (CSME) and AMD's Platform Security Processor (PSP, now called the AMD Secure Processor or ASP) are small, separate processors built into the chipset or SoC. They start before the main CPU, verify early firmware, host the firmware TPM and, on AMD servers, manage confidential computing keys.

Neither engine is something you can turn off and forget. Both run signed firmware that gets security fixes, both are updated only through your system maker's BIOS or firmware package, and both expose enough to the operating system that an admin can read versions and security state from Linux and Windows. This guide goes one level deeper than our post on what a firewall cannot see in firmware, BMCs and management engines: how each engine is built according to its vendor, how Intel Active Management Technology (AMT) differs from CSME itself, which advisories changed things, why the OEM sits in the update path, what network monitoring can and cannot see, the exact commands to check versions, and what Intel TDX and AMD SEV-SNP rely on. Every architectural claim comes from Intel, AMD, Linux kernel or fwupd documentation listed under Sources.

Key takeaways

• CSME is, in Intel's words, an embedded subsystem and PCIe device acting as the security and manageability controller in the Platform Controller Hub. Intel's white paper describes a dedicated 32 bit processor based on the Intel 486 architecture, 512 KB to 1,920 KB of private SRAM and a boot ROM that cannot be patched after manufacturing.
• CSME has three jobs according to Intel: silicon initialization (clocks, GPIO, loading firmware into other on chip engines), manageability (AMT on vPro systems) and security (Intel PTT firmware TPM, Boot Guard policy, DRM, signed applet loading).
• The AMD Secure Processor is the separate processor that handles SEV guest key management, runs AMD's firmware TPM ("ASP fTPM" in AMD's own bulletin tables), enforces Platform Secure Boot and rollback protection, and runs a small Secure OS with trusted applications.
• CSME is present on most Intel platforms, consumer ones included. AMT is an optional manageability feature on vPro SKUs that runs on CSME. A machine can have CSME without AMT; INTEL-SA-00075 (May 2017) did not affect consumer firmware, while INTEL-SA-00086 (November 2017) hit the CSME kernel regardless of AMT.
• Intel states that CSME firmware updates are delivered by OEMs, not by Intel. AMD ships fixes as Platform Initialization (PI) firmware packages to OEMs and tells customers to get the BIOS update from their OEM. If your vendor has not shipped a BIOS, you do not have the fix.
• On Linux, /sys/class/mei/mei0/fw_ver reports the ME firmware version, the ccp driver exposes PSP state such as fused_part, debug_lock_on and anti_rollback_status under /sys/bus/pci/devices/, and fwupdmgr security grades both engines in its Host Security ID checks.
• AMT traffic on a wired port goes straight to the engine, not through the host OS, so a host firewall never sees it. A network firewall sees it as traffic to TCP ports 16992 to 16995, 623 and 664, or as an outbound TLS tunnel when AMT uses Client Initiated Remote Access.
• AMD SEV-SNP depends directly on the Secure Processor: it manages guest keys and signs attestation reports, and committing new SNP firmware changes the reported TCB. Intel TDX depends on the CPU's SEAM mode, the BIOS and an Intel signed TDX module, which the Linux kernel can now update at runtime.

What is Intel CSME, and what does it run before and alongside the OS?

Intel's CSME Security Technical White Paper (document 631900, revision 1.5, October 2022, covering CSME 14.0 for Comet Lake, 15.0 for Tiger Lake and 16.0 for Alder Lake) describes CSME as a hardware based manageability and security controller isolated from the main CPU. It calls CSME "the system's root of trust for Intel components", and optionally for the OEM if the OEM chooses to use it.

Physically, CSME lives in the Platform Controller Hub (PCH), the chipset that sits beside the CPU. To the host it appears as a PCIe device. Its firmware and configuration are stored in non volatile memory, usually the same SPI flash chip that holds your BIOS. Intel says CSME is present on most Intel platforms: client consumer and commercial systems, workstations, servers and IoT products.

What hardware does CSME have?

According to the white paper, the security block contains:

Note that "ring" here means the CSME processor's own rings, not the main CPU's. A bug in CSME ring 3 is not a bug in your OS user space; it is code running on a different processor with access to platform secrets.

What does CSME do before the CPU runs your BIOS?

Intel lists three platform functions. The first is silicon initialization: base initialization of the PCH, including clocks and GPIO; authenticating and loading firmware into other hardware engines inside the CPU and PCH, such as the Power Management Controller, audio, camera, Type C and sensor firmware; and secure debug of the PCH.

The boot sequence Intel describes works like this:

1. At power on, the CSME boot ROM runs. Intel says the ROM is permanent hardware with no patching mechanism after silicon tape in, and once a high volume manufacturing fuse is set there is no way to bypass it on production parts.
2. The ROM uses DMA to load the compressed CSME image from SPI flash into internal SRAM and verifies it. The image is signed by Intel: RSASSA PSS with a 3072 bit RSA key and SHA 384 in CSME 15.0, and PKCS #1 v1.5 with a 2048 bit key and SHA 256 in CSME 14.0. The ROM holds a hash of the public key; the key itself and the signature travel in the firmware manifest. Intel says the private signing keys sit in an HSM and change with each major generation.
3. The ROM Boot Extension (RBE) continues the chain, then the CSME micro kernel, the trusted computing base OS and the BringUp module start.
4. BringUp coordinates with the BIOS during early boot, including how much host memory CSME reserves.
5. Services and applications start: the firmware TPM, Boot Guard support, AMT where licensed, and loaders for signed applets and other engines' firmware.

The security functions Intel lists are Intel Platform Trust Technology (PTT), an integrated TPM compliant with TCG TPM 2.0; Intel Boot Guard, where CSME stores the Boot Guard policy in PCH field programmable fuses so the CPU only runs an authentic OEM BIOS; hardware DRM; and secure loading of Intel signed Dynamic Application Loader applets and firmware for Thunderbolt, Type C and sensor engines.

What runs alongside the OS?

Once the OS is up, CSME keeps running. The OS talks to it through the Management Engine Interface (MEI, previously called HECI). The Linux kernel's MEI documentation describes the engine as "an isolated and protected computing resource" inside certain Intel chipsets, whose feature set depends on the chipset SKU. Each CSME feature is a client addressed by a GUID, and the kernel exposes character devices at /dev/meiX. Because some features can change system configuration, the driver allows only privileged users to open them by default.

In practice that means the TPM you see in Windows as an Intel TPM is a CSME application, the firmware update agent for CSME talks over MEI, and on vPro systems the AMT local manageability service talks over MEI too.

What is the AMD Platform Security Processor, and what does it own?

AMD now calls the PSP the AMD Secure Processor (ASP, sometimes AMD-SP). The Linux kernel's KVM documentation describes it plainly: SEV guest key management is handled by "a separate processor called the AMD Secure Processor (AMD-SP)", whose firmware provides a key management interface for launching, snapshotting, migrating and debugging encrypted guests. AMD's public bulletins and the interfaces it exposes to Linux fill in the rest.

What the Secure Processor owns, from AMD's own documents

The ccp driver also reports a bootloader_version (the firmware version of the AMD AGESA bootloader) and a tee_version (the firmware version of AMD's Trusted Execution Environment). Those two numbers are the closest thing Linux gives you to a PSP firmware version on supported client SoCs.

How does the PSP fit into boot?

AMD's architecture differs from Intel's in one important way: there is no separate chipset that houses the engine. The Secure Processor is part of the SoC. Its firmware lives in the same SPI flash as the BIOS, inside AMD's Platform Initialization package (the code AMD and OEMs call AGESA). Platform Secure Boot, which fwupd describes as a root of trust formed by fusing keys into the processor, is how the PSP checks that the BIOS it hands control to was released by the system manufacturer. The AMD side equivalent of Intel Boot Guard, in other words.

One thing this post will not do is describe the PSP's internal processor core. AMD's documents cited here describe what the Secure Processor does, not what core it uses, and we describe vendor features only from the vendor's own documents.

CSME and the PSP side by side

What is the difference between CSME and AMT (vPro), and is AMT provisioned?

This is the most misunderstood part of the topic. CSME is the engine. AMT is one application that runs on it, on systems sold with the vPro feature set.

Intel's white paper describes AMT as remote management "independent of the OS", reachable even when the platform is powered off as long as it has power and a network connection. The listed capabilities are serial over LAN, USB storage redirection, remote KVM, remote power control, scheduled wake, hardware asset inventory and out of band diagnostics, event management and Client Initiated Remote Access (CIRA) for machines outside the corporate network.

A consumer laptop has CSME (for PTT, Boot Guard, chipset bring up and the rest) but no AMT. Intel's INTEL-SA-00075 advisory says the AMT vulnerability it addressed "does not exist on Intel-based consumer PCs with consumer firmware". From CSME 15.0, Intel added an AMT hardware disable that turns off AMT hardware in non vPro SKUs.

The three AMT states that matter

AMT can be present but unconfigured. What counts is whether it is provisioned (activated). The open source Device Management Toolkit documents the states its rpc amtinfo command reports:

On 13th generation (Raptor Lake, AMT 16.1) and newer systems the tool also reports an operational state of enabled or disabled. Intel's white paper notes that CSME 14.0 added mutual TLS for host based provisioning and deprecated the less secure path of upgrading from CCM to ACM, and CSME 15.0 added AMT session attestation so a provisioning server can confirm it is talking to a genuine CSME.

How to tell whether AMT is provisioned

On Linux, run as root, with the mei_me driver loaded:

# Is there an MEI device at all?
ls /dev/mei* 2>/dev/null
cat /sys/class/mei/mei0/fw_ver

# Device Management Toolkit RPC client (needs root)
sudo ./rpc amtinfo -ver -sku -mode
sudo ./rpc amtinfo -json > amtinfo.json

On Windows, run the same rpc.exe amtinfo from an Administrator command prompt. The documentation says RPC must run with elevated privileges on both systems.

What to look for:

• Control Mode: pre-provisioning state on a fleet you do not manage with AMT is the expected, low exposure result.
• activated in client control mode or activated in admin control mode on a machine nobody in IT knows about is a finding. Someone activated it, and it holds credentials you need to own.
• The -lan section shows both the AMT IP address and the OS IP address. The documentation notes the AMT address shows 0.0.0.0 when CIRA is in use or the device is unactivated.
• The -ras section shows whether CIRA is connected to a management server and its host name. Periodic means a CIRA tunnel is up, with a heartbeat every 30 seconds by default.

fwupd also reads the AMT version over MEI. Its intel-amt plugin documentation says that if AMT is enabled and provisioned with a version between 6.0 and 11.2 and you have not upgraded the firmware, you are exposed to CVE-2017-5689 and should disable AMT in firmware.

Worked example: reading fw_ver

The kernel ABI documentation defines fw_ver as <platform>:<major>.<minor>.<milestone>.<build_no>, with up to three such blocks for different firmware components. Suppose a 7th generation Core desktop reports a CSME block of 11.8.50.3399.

INTEL-SA-00086 lists the fix for 6th and 7th generation Core as ME 11.8.50.3425 recommended, 11.8.50.3399 minimum. So this machine meets Intel's minimum for that advisory but not the recommended build. Comparing in order: major 11 equals 11, minor 8 equals 8, milestone 50 equals 50, build 3399 is lower than 3425. One advisory is not the whole story, though. INTEL-SA-00213 later listed 11.8.65 as the fixed CSME line for CVE-2019-0090, and 11.8.50 is lower than that. The right answer for this machine is the newest CSME firmware its OEM has published, then a rerun of Intel's detection tool.

Which vendor advisories mattered, and what did they change?

Described from the vendor advisories only. No exploit detail.

Timeline

INTEL-SA-00075 (May 2017): AMT on the network

This is the advisory that made management engines a boardroom topic. It covered Intel Active Management Technology, Intel Standard Manageability (ISM) and Intel Small Business Technology firmware versions 6.x through 11.6. Intel rated it 9.8 critical for an unprivileged network attacker and 8.4 for an unprivileged local attacker. The network path applied to AMT and ISM once provisioned; Small Business Technology was affected only locally.

The fixed builds, per Intel, all carry a four digit build number starting with 3, for example 11.6.27.3264 or 9.1.41.3024. Intel's guidance was to get updated firmware from the OEM first and use its mitigation guide if none was available. The US-CERT alert of the time also points to an unprovisioning tool, which is the cleanest mitigation if you never meant to use AMT.

What it changed: admins learned to inventory AMT provisioning state, not just presence, and that firmware fixes for a chipset engine arrive on the OEM's schedule.

INTEL-SA-00086 (November 2017): the engine's own kernel

Intel's "Q3'17" cumulative update covered ME 6.x to 11.x, Server Platform Services 4.0 and Trusted Execution Engine 3.0. The kernel level flaws (for example CVE-2017-5705, rated 8.2) needed local or physical access, and one AMT flaw, CVE-2017-5712, was reachable over the network by a remote administrator. The affected list spans 1st to 8th generation Core, Xeon E3-1200 v5 and v6, Xeon Scalable, Xeon W, Atom C3000, Apollo Lake and several Pentium and Celeron lines.

Three details matter for admins:

• Intel said ME 6.x and 7.x would not receive updates because they were no longer supported.
• Intel said full restoration needs both the ME firmware update and the Intel Capability Licensing Service software update, and it published a Linux recovery tool to re provision platform keys after the firmware update.
• fwupd's Host Security ID check for CSME version cites exactly the eight CVEs from this advisory. A machine that fails org.fwupd.hsi.Mei.Version is one that fwupd considers exposed to them.

What it changed: CSME bugs were no longer only an AMT problem. Every Intel machine with the affected firmware lines needed a BIOS or ME update, vPro or not.

INTEL-SA-00213 (May 2019) and CVE-2019-0090

The 2019.1 quarterly release covered CSME, SPS, TXE, DAL and AMT. CVE-2019-0090 is described as insufficient access control in a CSME 11.x subsystem that could let an unauthenticated user escalate privilege through physical access, rated 7.1. Intel listed fixed CSME lines 11.8.65, 11.11.65, 11.22.65 and 12.0.35, and stated that ME 3.x to 10.x, TXE 1.x to 2.x and SPS 1.x to 2.x were out of support and would not get releases. The advisory also links a separate Intel technical white paper for this CVE.

What it changed: physical access findings became part of the patch cycle, and older lines were formally left behind. It also shows why the newer recovery features in Intel's white paper matter: hardware anti rollback from CSME 12.0, an on die certificate authority from CSME 15.0 replacing EPID, and TCB recovery that moves keys forward after a security fix. Because Intel says the CSME boot ROM cannot be patched, anything at that layer can only ever be handled by the firmware above it.

AMD-SB-4004 and AMD-SB-3003 (August 2024): the Secure Processor and SEV

AMD published client and server bulletins on 13 August 2024 for potential vulnerabilities in the AMD Secure Processor and other platform components. The client bulletin lists, among others, an APCB out of bounds write (CVE-2022-23815, 7.5), a buffer checking flaw in the ASP's Secure OS reachable from a malicious trusted application (CVE-2022-23817, 7.0) and a Trusted Memory Region misconfiguration issue (CVE-2021-26367, 5.7). The server bulletin adds SEV and SEV-SNP issues, including improper key usage control in the ASP (CVE-2024-21981, 5.7).

The fix format is the part admins need. AMD lists minimum PI versions, for example ComboAM4V2 1.2.0.A (dated 21 March 2023) or ComboAM5 1.0.8.0 (29 August 2023) for desktop parts, and tells customers to get the product specific BIOS update from their OEM. The client bulletin also marks at least one CVE as having no fix planned for some product lines. Read the row for your exact processor family.

AMD-SB-7033 (March 2025): microcode signatures

AMD-SB-7033 is not a PSP flaw in the narrow sense, but it shows how tightly the firmware stack is tied together. External researchers reported that a weakness in the CPU ROM microcode patch loader's signature verification could let an attacker with administrator privilege load microcode AMD had not signed (CVE-2024-36347, 6.4). AMD's fix ships as PI firmware to OEMs, and for data center parts AMD tells you which microcode revision confirms the mitigation is installed. fwupd added a matching HSI check, org.fwupd.hsi.Amd.EntrySign, in version 2.1.2.

AMD-SB-4011 (June 2025): the firmware TPM

The Trusted Computing Group's vulnerability response team reported an out of bounds read in the TPM 2.0 reference implementation (CVE-2025-2884, 6.6). AMD concluded that its firmware TPM, which its tables list as "ASP fTPM", was affected, and released PI firmware to OEMs, with table updates in July and August 2025. Any firmware TPM built on the affected reference code needs the same attention, which is a reminder that the TPM in a modern laptop is a firmware application on a security processor, patched the same way as everything else below the OS.

How are these firmwares updated, and why do OEMs gate the updates?

Intel

Intel's white paper is direct: new CSME firmware is delivered to end users by individual OEMs, not by Intel. The update is installed by a software agent over HECI, the update process is fault tolerant against interruption, and a firmware enforced version control mechanism blocks downgrades through the update interface. A hardware enforced mechanism, which the OEM manages, burns the anti rollback security version number (SVN) into field programmable fuses so CSME refuses to boot an older, vulnerable image even if someone reflashes the SPI chip directly.

AMD

AMD's bulletins use the same wording every time: mitigations are released to OEMs in Platform Initialization firmware packages, and you contact your OEM for the BIOS update for your product. The PSP firmware, the AGESA code that initializes the platform and, often, microcode updates all arrive inside one OEM BIOS image.

Why the OEM is in the path

The vendor documents give several reasons, all structural:

1. The firmware lives in the OEM's flash image. Intel says CSME firmware is stored in NVM as part of the system firmware along with the BIOS, microcode patch and Authenticated Code Module. The OEM builds and validates that image for each board.
2. The OEM owns platform keys and fuses. Boot Guard and Platform Secure Boot keys are fused by the manufacturer. Intel's hardware anti rollback is described as an OEM managed capability.
3. The OEM closes manufacturing. Intel's End of Manufacturing step, which it calls mandatory, writes and locks manufacturer settings into fuses, closes debug and manufacturing APIs and locks the SPI flash descriptor. From CSME 16.0, Intel split this step into three stages in response to OEM requests, to reduce missed End of Manufacturing steps. fwupd's HSI checks for manufacturing mode and the flash descriptor override strap exist because some systems shipped without it.
4. Configuration is board specific. Clocks, GPIO, memory reservations and which engine features are licensed differ per SKU and per board.

The cost of this design is time and coverage. A fix released by Intel or AMD reaches your machine only when your OEM ships a BIOS for that model, and older models may never get one. Our post on why firmware below the OS goes unpatched covers that gap in detail. NIST SP 800-193 (May 2018) frames the goal for platform firmware as protect, detect and recover, and points administrators at procurement as one of the levers they actually have: buy platforms whose makers commit to firmware support.

Rollback and attestation interact

Once you update, you may not be able to go back. Intel says that once firmware with security mitigations is installed, it may not be possible to downgrade. AMD's SNP firmware has an explicit SNP_COMMIT step that, per the Linux docs, prevents rollback to a previously committed firmware version and updates the reported TCB. Plan updates so that you test before you commit, and so that attestation verifiers know the new TCB values before the fleet reports them.

What can a firewall see of AMT traffic, and what can it not see?

Intel's AMT Implementation and Reference Guide lists the manageability ports:

From CSME 16.1, remote connections to 16992, 16994 and 623 are no longer supported, and from CSME 19 on Arrow Lake, connecting to AMT without TLS is not supported at all, locally either.

What the host firewall cannot see

The same guide explains routing. On a wired LAN, messages to these ports go directly to AMT. On wireless, they go to the host's wireless driver, which spots the destination port and forwards the message to AMT. So on a wired connection, a host based firewall on Windows or Linux never sees inbound AMT traffic at all, because the NIC hands it to the engine before the OS gets it. Intel even warns that if host software uses one of these ports as a source port, the reply is routed to AMT and the host never sees it.

What a network firewall can see

• Inbound connections to TCP 16992 to 16995, 623 and 664 addressed to the machine. In a shared IP setup the AMT IP address and the OS IP address are the same, so the traffic looks like it targets the host. rpc amtinfo -lan shows both addresses.
• With TLS ports, only metadata: source, destination, port, timing and certificate details in the handshake. The WS-Management content is encrypted.
• With CIRA, an outbound TLS connection from the machine to a management presence server, with a periodic heartbeat. To a perimeter firewall this looks like any other outbound TLS session to the server named in rpc amtinfo -ras.

What a firewall cannot tell you

A firewall cannot tell you whether AMT is provisioned on a machine that is not currently talking, what CSME firmware version it runs, or whether the engine has been tampered with. Those answers come from the endpoint checks below. If your policy is that AMT is unused, block 16992 to 16995, 623 and 664 at segment boundaries, alert on outbound connections to unknown management servers, and verify on each endpoint that the control mode is pre-provisioning.

How do you check versions and security state on Linux?

All of these are read only.

Step 1: identify the engine and load the drivers

# CPU vendor and model
grep -m1 -E 'vendor_id|model name' /proc/cpuinfo
lscpu | grep -E 'Vendor ID|Model name'

# BIOS version and date, which is what carries CSME or PSP firmware
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date

# Intel: MEI devices; AMD: PSP shows up through the ccp driver
lsmod | grep -E '^mei|^ccp'
ls /dev/mei* /dev/sev 2>/dev/null

Step 2: Intel CSME version and state

cat /sys/class/mei/mei0/fw_ver      # <platform>:<major>.<minor>.<milestone>.<build_no>
cat /sys/class/mei/mei0/dev_state   # ENABLED, RESETTING, DISABLED, ...
cat /sys/class/mei/mei0/fw_status   # raw status registers, decoding varies by PCH generation
cat /sys/class/mei/mei0/kind        # "mei" for the generic device

The kernel ABI documentation explains that fw_status holds the firmware's running state, power state and error codes, decoded differently by PCH or SoC generation, and that there can be one to six registers. Keep the raw values in your inventory; they help support teams.

Step 3: AMD Secure Processor state

for d in /sys/bus/pci/devices/*; do
  if [ -e "$d/fused_part" ] || [ -e "$d/tsme_status" ]; then
    echo "== $d"
    for a in fused_part debug_lock_on anti_rollback_status rpmc_production_enabled \
             tsme_status bootloader_version tee_version; do
      [ -r "$d/$a" ] && printf '%-26s %s\n' "$a" "$(cat "$d/$a")"
    done
  fi
done

What each value means, per the kernel's sysfs-driver-ccp documentation:

fwupd's PSP plugin documentation warns that a missing file does not mean a missing feature, only that the SoC does not export it to the OS. Absence is "unknown", not "fail".

Step 4: run fwupd's Host Security ID checks

fwupdmgr --version
fwupdmgr security
fwupdmgr get-devices

fwupd 1.8.4 or later makes per test recommendations. The attributes that concern these engines are:

The fwupd documentation describes the risks plainly. If the ME is in manufacturing mode, any user with root can provision the engine with new keys; if the override strap is unlocked, root can write persistent code to system firmware that survives a disk wipe. Every one of these lists "Contact your OEM" as the resolution, which tells you who has to fix it.

Step 5: Intel's own detection tool on Linux

Intel's CSME Version Detection Tool (download 19392; version 15_0_4_0022 was listed as latest on 25 August 2026) ships a Linux command line executable that prints a risk assessment against Intel's advisories. Download it from Intel, verify the published hash, and follow the user guide in the package. For ME 6.x to 10.x systems Intel publishes a separate legacy detection tool.

Step 6: AMD microcode and confidential computing state

grep -m1 microcode /proc/cpuinfo           # compare with the revision AMD lists per PI version
sudo dmesg | grep -iE 'sev|snp|ccp'         # SEV and SNP initialization messages on AMD hosts
sudo dmesg | grep 'virt/tdx'                # Intel TDX: BIOS KeyID range, module load and init
cat /sys/devices/faux/tdx_host/seamldr_version 2>/dev/null   # newer kernels with TDX runtime update

The kernel TDX documentation shows the messages to expect: virt/tdx: BIOS enabled: private KeyID range, virt/tdx: module not loaded if the BIOS did not load the module, and virt/tdx: TDX-Module initialized on success.

How do you check versions on Windows?

Windows does not expose the CSME version through a built in cmdlet, so use the vendor tools:

1. Intel CSME Version Detection Tool. The Windows package has an interactive GUI for a single machine and a console executable that writes results to the registry or an XML file, which Intel positions for bulk discovery across a fleet. Push the console version through your software distribution tool and collect the XML.
2. AMT state. Run rpc.exe amtinfo -json from the Device Management Toolkit in an Administrator prompt and collect the JSON.
3. Firmware TPM. Get-Tpm shows ManufacturerIdTxt and ManufacturerVersion. Microsoft's example output shows INTC, the Intel identifier. A firmware TPM reports the CPU vendor, so this tells you whether BitLocker is sealing to PTT, AMD fTPM or a discrete chip.
4. BIOS version. Get-CimInstance Win32_BIOS | Select-Object SMBIOSBIOSVersion, ReleaseDate gives the BIOS that carries the CSME or PSP firmware. Compare it with the OEM's release notes, which name the ME or AGESA version and the advisories fixed.

Get-Tpm | Select-Object TpmPresent, TpmReady, ManufacturerIdTxt, ManufacturerVersion
Get-CimInstance Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate
Get-CimInstance Win32_Processor | Select-Object Name, Manufacturer

On AMD Windows machines there is no AMD equivalent of the CSME detection tool among the documents cited here. The practical check is the BIOS version against the minimum PI version in the AMD bulletin row for your processor, read through the OEM's release notes.

What do TDX and SEV-SNP depend on from these engines?

AMD SEV-SNP: the Secure Processor is in the trusted computing base

For SEV, SEV-ES and SEV-SNP, the AMD Secure Processor is not a bystander. The Linux docs describe it as the firmware that manages guest keys and handles launch, snapshot, migration and debug. For SNP attestation, the guest asks the firmware for a report, and the firmware signs it with either a VCEK, derived from chip unique secrets, or a VLEK, obtained from AMD's key distribution service for enrolled cloud providers.

Three consequences for admins:

• The PSP firmware version is part of what you attest. The reported TCB includes the firmware state. A verifier that pins an old TCB will reject correctly updated hosts, and one that accepts any TCB will accept hosts that missed a fix.
• Commit is a one way door. SNP_COMMIT prevents rollback to a previously committed firmware version and updates the reported TCB. SNP_SET_CONFIG can set the reported TCB version. The KVM docs warn that tools that change TCB values or endorsement keys need to coordinate with VMMs that serve certificate blobs.
• Server bulletins name SEV explicitly. AMD-SB-3003 lists ASP, SEV and SEV-SNP issues fixed in EPYC PI firmware. If you run confidential VMs on AMD, the PSP's patch level is a guest security property, not only a host one.

Intel TDX: the CPU's SEAM mode, the BIOS and the TDX module

Per the Linux kernel documentation, TDX introduces a CPU mode called Secure Arbitration Mode (SEAM) and an isolated memory range. An Intel signed "TDX module" runs there and manages protected VMs, using multi key total memory encryption with KeyIDs that the BIOS partitions. The BIOS usually holds a copy of the TDX module in flash and loads it at boot, and a persistent SEAM loader (P-SEAMLDR) can replace it at runtime. The kernel docs say runtime loaded modules do not change the BIOS flash and do not survive a reboot.

So the dependencies for TDX are the CPU and its microcode, the BIOS (which must enable TDX and partition KeyIDs), the TDX module version and the P-SEAMLDR version. The kernel docs do not route TDX through CSME. CSME's relevance to TDX is indirect: it verifies early firmware and, with Boot Guard, helps make sure the BIOS that loads the TDX module is the OEM's. If you run TDX hosts, track BIOS version, microcode revision and TDX module version together, and plan module updates with the compatibility rules in the kernel docs (supported CPU family and stepping, minimum P-SEAMLDR version and compatibility with the running module).

Comparison for confidential computing teams

A step by step audit you can run this week

1. Inventory models and BIOS versions. Collect vendor, model, BIOS version and date from every machine (dmidecode or Win32_BIOS). Group by model; one BIOS release fixes a whole group.
2. Collect engine versions. Linux: fw_ver for Intel, ccp attributes for AMD. Windows: CSME Version Detection Tool console XML for Intel.
3. Run fwupd HSI on Linux. Save fwupdmgr security output per host. Treat a fail on Mei.ManufacturingMode, Mei.OverrideStrap or PlatformFused as a procurement issue to raise with the OEM, not something you fix in software.
4. Check AMT control mode. Run rpc amtinfo -mode everywhere you have Intel vPro hardware. Every activated machine needs a known owner and known credentials. If you do not use AMT, deactivate it through your management tooling or the firmware setup, and disable it in BIOS where the OEM allows.
5. Map to advisories. For each model, read the OEM's BIOS release notes for the ME or AGESA version and the INTEL-SA or AMD-SB numbers they fix. Use the minimum versions in the advisories as a floor.
6. Update in rings. Suspend BitLocker or plan for TPM resealing first, because a BIOS update usually changes PCR values. Our TPM PCR guide covers which PCRs move. On SEV-SNP hosts, test before SNP_COMMIT.
7. Verify after. Rerun steps 2 to 4. A BIOS that installed but did not update the engine shows up here.
8. Watch the network. Block AMT ports at segment boundaries if unused, and alert on outbound connections to unknown management servers.
9. Record end of support. Intel has stated that older ME lines get no new releases. Machines on those lines need a hardware refresh plan, not a ticket that stays open.

Common mistakes

• Treating "no vPro" as "no engine". Every modern Intel PC has CSME and every modern AMD PC has the Secure Processor. SA-00086 affected consumer and business systems alike.
• Checking AMT presence instead of provisioning. Present but in pre-provisioning state is low exposure. Activated with unknown credentials is the problem.
• Relying on the host firewall. On wired connections, AMT traffic never reaches the host OS. Only the network sees it.
• Waiting for Intel or AMD to ship the update. They ship to OEMs. If your OEM has not published a BIOS, you do not have the fix.
• Reading a missing sysfs file as a failure. On AMD, a missing ccp attribute means the SoC does not export that value, not that the protection is absent.
• Updating confidential computing hosts without telling the verifier. A new PSP or TDX module version changes attestation evidence. Update the verifier's reference values first.
• Forgetting the TPM. Intel PTT and AMD fTPM are firmware applications on these engines. A BIOS update can change PCRs and trigger BitLocker recovery if you did not suspend first.
• Assuming one advisory's minimum is enough. A version that clears SA-00086 can still be below the fix line for SA-00213. Track the newest OEM release, not one advisory.

FAQ

Can I disable the Intel Management Engine completely?

Not on supported production systems. Intel describes CSME as part of silicon initialization: it configures clocks and GPIO and loads firmware into other engines, so a platform cannot run normally without it. What you can do is leave AMT unprovisioned or disabled, and on newer non vPro SKUs Intel says AMT hardware can be disabled. fwupd's CSME check treats an engine disabled through the HAP setting as passing, but setting that is an OEM or specialist operation, not a fleet control.

Does my consumer laptop have AMT?

Usually not. Intel's SA-00075 advisory states the AMT vulnerability did not exist on consumer PCs with consumer firmware. AMT comes with vPro business SKUs. Your laptop still has CSME, which runs PTT, Boot Guard and chipset bring up.

How do I check the Intel ME version on Linux?

Read /sys/class/mei/mei0/fw_ver. The kernel defines the format as platform, then major, minor, milestone and build number, with up to three blocks for different components. You can also run fwupdmgr security for a pass or fail on known CSME advisories, or Intel's CSME Version Detection Tool for Linux.

How do I check the AMD PSP firmware version on Linux?

On supported SoCs, the ccp driver exposes bootloader_version and tee_version under the PSP's PCI device in /sys/bus/pci/devices/. The kernel docs describe these as the AGESA bootloader and AMD TEE firmware versions. For fixes, compare your BIOS version with the minimum PI version AMD lists in its bulletin for your processor family.

Is the AMD fTPM part of the PSP?

Yes, according to AMD. Its AMD-SB-4011 bulletin lists the affected TPM on client processors as "ASP fTPM", and the fix shipped as PI firmware through OEM BIOS updates.

Which ports does Intel AMT use?

According to Intel's AMT reference guide: 16992 and 16993 for WS-Management over HTTP and HTTPS, 16994 and 16995 for redirection over TCP and TLS, 623 and 664 for RMCP and secure RMCP. The non TLS ports 16992, 16994 and 623 are deprecated and no longer supported for remote connections from CSME 16.1.

Does TDX depend on the Intel ME?

Not directly, according to the Linux kernel documentation, which describes TDX as a CPU mode (SEAM) running an Intel signed TDX module that the BIOS loads and the kernel can update at runtime. CSME matters indirectly because it helps verify the platform firmware that loads that module.

What does fwupd's HSI score tell me about the engines?

It runs specific checks, such as ME version, manufacturing mode, override strap, Boot Guard, AMD Platform Secure Boot, rollback protection and debug lock, and maps passes to levels from HSI:1 upward. A low score caused by an engine check almost always resolves with an OEM firmware update or a different hardware purchase.

Where Safeguard fits, honestly

Safeguard does not scan firmware binaries, read MEI or ccp state, manage devices or generate a hardware bill of materials. What does touch this topic is the software around the engines that you build and ship: fwupd, the tpm2 software stack, AMT management agents and RPC clients, attestation verifiers for SEV-SNP and TDX, and the container images that run them. Those are open source components with their own advisories, and they deserve the same version hygiene as any application dependency.

The engines themselves are patched only by your OEM, but the tools you use to check and attest them are ordinary open source software that gets rebuilt and redeployed like anything else. A fleet audit script, a verifier service or a rebuilt management image pulls dependencies again each time, so the same supply chain hygiene applies, with the honest limit that the firmware fix still comes from Intel, AMD and your system maker.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

To be plain about scope: Safeguard will not tell you a CSME version, an AMT control mode or a PSP rollback setting. Those come from the commands above and from your OEM. What Safeguard does is scan the software you build and ship, with safeguard scan --dir ., --image <name> or --sbom <file>, and show which projects contain a given component and version. For this topic that means the repositories and images behind your fleet audit scripts, attestation verifiers and management agents.

This first demo is a real CLI session. You install the CLI, run safeguard to open the interactive terminal and ask it to fix a lodash CVE; it reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. The same ask before every command flow applies to the repository that builds your attestation verifier or inventory collector.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine: you approve it with its device code, then scan from the terminal. That suits the admin workstation or build host where your fwupd tooling, RPC clients and audit scripts are assembled, so the scan runs where the files already are.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. If your team uses Claude to work through firmware audit results, this is how to let it ask Safeguard which of your projects carry a given package version, limited to the tools you approve.

Click through it at your own pace, or open it full screen.

You can download Safeguard or read the CLI documentation to try it on your own build.

Quick check

Sources

• Intel CSME Security Technical White Paper, document 631900, revision 1.5 (PDF)
• Intel INTEL-SA-00075: AMT, ISM and SBT escalation of privilege
• Intel INTEL-SA-00086: ME, SPS and TXE security review cumulative update
• Intel INTEL-SA-00213: CSME, SPS, TXE, DAL and AMT 2019.1 QSR
• Intel AMT Implementation and Reference Guide: manageability ports
• Intel CSME Version Detection Tool (download 19392)
• Device Management Toolkit: RPC commands, including amtinfo
• CISA archived alert: Intel Firmware Vulnerability (May 2017)
• CISA archived alert: Intel Firmware Vulnerability (November 2017)
• AMD-SB-4004: Client Vulnerabilities, August 2024
• AMD-SB-3003: Server Vulnerabilities, August 2024
• AMD-SB-7033: CPU Microcode Signature Verification Vulnerability
• AMD-SB-4011: TPM Reference Implementation (fTPM)
• fwupd: Host Security ID specification
• fwupd plugin: intel-amt
• fwupd plugin: intel-me-pci
• fwupd plugin: intel-me-smbios
• fwupd plugin: intel-mkhi
• fwupd plugin: pci-psp
• Linux kernel: Intel Management Engine Interface (MEI)
• Linux kernel: ABI testing symbols, including sysfs-class-mei and sysfs-driver-ccp
• Linux kernel: Intel Trust Domain Extensions (TDX)
• Linux kernel: KVM AMD memory encryption (SEV, SEV-ES, SEV-SNP)
• Linux kernel: The Definitive SEV Guest API Documentation
• Linux kernel: AMD Memory Encryption
• NIST SP 800-193: Platform Firmware Resiliency Guidelines
• Microsoft Learn: Get-Tpm

Last reviewed: 24 October 2026. Engine firmware, advisories and tool versions change often; check the linked vendor pages and your OEM's BIOS release notes for your exact models.