What a Firewall Cannot See: Firmware, BMCs and Management Engines

A firewall cannot see code that runs below or beside the operating system: server BMCs, Intel AMT and the Management Engine, the AMD Secure Processor, and the firmware inside network cards and modems. A host firewall only filters packets that reach the OS network stack, and out of band management traffic can be diverted to its own controller before that happens. You protect those layers with a separate management network, changed defaults, disabled features you do not use, firmware updates and access logs.

Most security programmes stop at the operating system: endpoint agents, host firewalls and scanners all run under the OS on the main CPU. Yet every modern server and most business PCs contain at least one other computer that boots first, keeps running when the host is off, and can reach the network on its own. This guide covers each one, how its traffic flows, what vendors and agencies say, and a hardening sequence with real commands.

Key takeaways

• A host firewall filters the OS network stack. Microsoft describes Windows Firewall as a host based firewall that filters traffic entering and exiting the device. Traffic consumed by a management controller never reaches it.
• Intel says so directly. Its vPro privacy page states that an operating system firewall will not block access to Intel AMT ports, and its reference guide says wired LAN messages to those ports go directly to AMT.
• BMCs are full computers with their own network path. NSA and CISA (June 2023) note that BMCs run independently of the OS and keep working when the server is shut down.
• Shared ports hide the split. With DMTF's NC-SI, the server's network controller forwards management frames to the BMC over a sideband, so one cable carries two separately filtered worlds.
• Default credentials and old protocols are the common failure. CISA's 2013 IPMI alert already listed default passwords, "cipher 0" and internet exposure.
• Firmware has its own patch stream. Intel CSME, AMT, AMD platform firmware and BMC images get advisories on their own schedule and usually reach you through the server or PC maker.
• NIST SP 800-193 is the framework. Protect firmware from unauthorised change, detect corruption, and recover to a known good state.

What does a firewall actually see?

The word "firewall" covers two things, and neither covers out of band management by default.

Host firewalls

A host firewall runs inside the operating system. Microsoft's overview describes Windows Firewall as "a host-based firewall that is included with the operating system and enabled by default." It filters traffic by source and destination address, protocol, port, application or service, and interface type. By default it blocks unsolicited incoming traffic and allows outgoing traffic unless a rule says otherwise. On Linux the equivalent is netfilter, configured through nftables or a front end, and macOS has its own application firewall.

The limit is in the definition: a host firewall sees packets only after the network card hands them to the OS driver and stack. A packet delivered somewhere else first is invisible to it: not logged, not blocked, not counted.

Network firewalls

A network firewall sits between segments and filters whatever crosses it, regardless of which chip on the destination consumes the packet. That makes it the right tool for out of band management, but only if management interfaces sit on a segment it actually separates. A BMC on the same flat VLAN as production is reachable by anything on that VLAN.

The third path: out of band management

Out of band management means managing a machine without relying on its operating system. NIST SP 800-193 puts it plainly: a core aspect of a BMC or Management Engine is "to serve as an out-of-band management device" that lets administrators manage a platform "without requiring the host operating system to be running." That is the feature. It is also the reason the host firewall is irrelevant to it.

The rest of this post works down that table.

What is a BMC, and why does it sit outside the host firewall?

A baseboard management controller is a small computer soldered onto a server motherboard. It has its own processor, memory, flash, operating system (often an embedded Linux) and network interface. It reads sensors, controls power, exposes a remote console, mounts virtual media, updates firmware and keeps an event log. CISA's 2023 alert describes BMCs as operating independently of the operating system and able to function even when a machine is powered off.

It has its own attack surface (web server, TLS library, SSH daemon, IPMI and Redfish services) maintained by the board or server maker. Our post on the BMC firmware supply chain covers where that software comes from, and the motherboard evolution post covers how the BMC became standard.

IPMI: the old protocol that still ships

The Intelligent Platform Management Interface is the older BMC protocol. In July 2013, US-CERT (now part of CISA) published alert TA13-207A, "Risks of Using the Intelligent Platform Management Interface (IPMI)." It warned that IPMI gives low level access that can override operating system controls, and that attackers who reach an exposed interface can often use default or missing passwords or weak encryption. Its recommendations still read like a current checklist:

• Restrict IPMI traffic, "usually UDP port 623," to trusted internal networks such as a management VLAN.
• Use strong, unique passwords and enable encryption where possible.
• Disable "cipher 0," which on many devices allows authentication bypass, and disable anonymous logins.
• At end of life, clear stored passwords per the maker's guidance, or destroy the component that holds them.

The alert is archived and CISA notes it may be dated, but none of those points has stopped being true.

Redfish: the modern API

DMTF developed Redfish as the modern replacement for IPMI. The Redfish Specification (DSP0266) records version 1.0.0 as its initial release on 4 August 2015, and the current version, 1.25.0, is dated 7 August 2026. Redfish is a RESTful API over HTTPS with a JSON data model, and it exposes the same powers IPMI did, plus more: power and reset actions on the system, account and role management, firmware inventory and update, log services, and virtual media.

The specification sets a reasonable security floor. Implementations "shall support" TLS 1.2 or later, should only support cipher suites marked "Recommended" by IANA, must allow the default certificate to be replaced, and must require HTTPS for HTTP Basic authentication. It also defines a PasswordChangeRequired property so a maker can force a change of factory credentials before first use. Whether your BMC enforces it depends on its firmware.

Redfish also lets you see and switch off the older protocols. The ManagerNetworkProtocol resource lists each service the BMC offers, including HTTP, HTTPS, IPMI, SSH, SNMP, KVMIP, VirtualMedia, Telnet and others, each with ProtocolEnabled and Port properties. We use that in the walkthrough below.

Dedicated versus shared management ports

Server makers usually give you two ways to cable a BMC:

• A dedicated management port connected only to the BMC. It is the easiest to isolate, because the cable can go to a management switch with no path to production.
• A shared port, where the BMC borrows one of the host's network ports. It saves cabling and is often the default on smaller servers.

Shared ports work through DMTF's Network Controller Sideband Interface (NC-SI, DSP0222, version 1.2.0 dated 25 August 2023). The specification describes a sideband between the network controller and the management controller, intended "to provide network access for the Management Controller." The network controller applies filters, by MAC address, VLAN tag and limited L3 and L4 header fields, and "all frames that pass frame filtering are forwarded to the Management Controller over the Sideband Interface."

From the host's point of view, a frame for the BMC arrives on the production cable, the network controller recognises it and sends it up the sideband. The host OS never receives it, so the host firewall never evaluates it. With a shared port, only a network firewall can protect the BMC, and the BMC should at least sit on its own VLAN.

How do Intel AMT and the Management Engine reach the network?

Intel's Converged Security and Management Engine (CSME, often just "the ME") is a coprocessor in the chipset. The Linux kernel documentation describes it as "an isolated and protected computing resource (Co-processor) residing inside certain Intel chipsets," with the host talking to it through the Management Engine Interface (MEI, previously HECI). On business PCs sold with Intel vPro, the ME firmware includes Intel Active Management Technology (AMT): remote power control, a remote keyboard, video and mouse session, and storage redirection.

Which ports, and what the host firewall can do about them

Intel's AMT Implementation and Reference Guide lists the ports AMT may listen on:

The routing rule is the key part. Intel's guide says "messages received on a wired LAN interface go directly to Intel AMT." On wireless, messages go to the host wireless driver, which "detects the destination port and sends the message to Intel AMT." Intel's privacy page for AMT is even blunter: "A operating system firewall will not block access to Intel® AMT ports." The same page says AMT can be used to troubleshoot "even when the host OS is off or damaged."

So on a wired, AMT enabled PC, your Windows Firewall rules have no effect on those ports. That is by design: remote management the OS could block would be useless for fixing a broken OS.

Intel has tightened the defaults over time. According to the same reference guide, from Alder Lake platforms with Raptor Lake CPUs running CSME 16.1 firmware, remote connections to the unencrypted ports 16992, 16994 and 623 are no longer supported, and TLS ports must be used. From CSME 19 firmware on Arrow Lake platforms, connecting to AMT without TLS "is not supported at all," including local connections. Older fleets do not get that benefit.

Provisioned, unprovisioned and disabled

A PC can be AMT capable but unprovisioned, provisioned with credentials and usually TLS, or have AMT disabled in firmware. Intel's privacy page says "Intel AMT provides BIOS options to partially/fully unprovision an Intel AMT system" and that it documents how to enable and disable AMT capabilities. Menu names vary by PC maker, so use your maker's documentation for the exact steps.

Consumer PCs without vPro do not include AMT, but they still have an ME running firmware for other functions. "No AMT" does not mean "no ME."

Real advisories as context

Intel's own advisories show why this layer needs its own patch process:

• INTEL-SA-00075 (1 May 2017), CVE-2017-5689. An unprivileged network attacker could gain system privileges on provisioned AMT and Intel Standard Manageability systems. Intel rated the network issue 9.8 (Critical) under CVSS 3.0, and a related local issue 8.4. Affected firmware ran from 6.x through 11.6, fixed by system maker firmware updates.
• INTEL-SA-00086 (20 November 2017). After a security review prompted by external research, Intel published fixes for ME 11.x, Server Platform Services 4.0 and TXE 3.0. Intel's summary says the issues could let an attacker run code that the user and the operating system cannot see. Most required local access, and one could be reached over the network with remote admin access.
• INTEL-SA-01427 (11 August 2026). A recent chipset firmware advisory covering Intel AMT and Intel Standard Manageability, rated High overall. One of its CVEs, CVE-2026-20715, is a network reachable denial of service that needs no authentication (CVSS 4.0 score 8.2). Intel again recommends updating "to the latest version provided by the system manufacturer."

Across nine years the pattern holds: the code runs below the OS, the fix comes as firmware through the PC or server maker, and the host firewall is not a mitigation.

What is the AMD Secure Processor, and is it a network risk?

AMD's equivalent of a security coprocessor is the AMD Secure Processor (ASP, historically called the Platform Security Processor or PSP). It runs its own bootloader and firmware from early in the boot process, separate from the operating system. Unlike AMT, it is not presented as a remote management service that listens on the network for administrators.

It still gets vulnerabilities. AMD-SB-4013, first published on 10 February 2026, covers Athlon and Ryzen client processors and includes CVE-2025-29951, a buffer overflow in the ASP bootloader that AMD says "could allow an attacker to overwrite memory, potentially resulting in privilege escalation and arbitrary code execution" (CVSS 4.0 score 7.3, local vector). The bulletin also lists System Management Mode and on chip debug interface issues.

The remediation model matters most here. AMD says it released mitigations to PC makers as new Platform Initialization (PI) firmware versions on listed dates, and tells users to contact their PC maker "for the BIOS update specific to your product(s)." Some entries say no fix is planned. In practice, AMD firmware fixes reach you as a BIOS or UEFI update from your PC, motherboard or server maker.

Business PCs on either platform may also implement DMTF's DASH standard for out of band management. Intel's privacy page notes that DASH compliant systems use port 623 for HTTP and 664 for HTTPS. If your fleet has DASH turned on, treat those ports the same way you treat AMT.

What about NIC, Wi-Fi and baseband firmware?

Every network interface is a small computer too. NIST SP 800-193 lists the network interface controller as a platform device whose firmware needs protection, and its reasoning is direct: "a compromised NIC firmware image could serve as a launch pad for other exploits in the system, be used to exfiltrate data, serve as a man-in-the-middle," among other things. It also notes that a NIC may carry expansion ROM firmware that the host CPU runs during boot, and that the MAC address itself is critical data stored in mutable memory.

SP 800-193 includes wired, Wi-Fi and cellular controllers. A laptop with a WWAN modem, and every phone, has a baseband processor running its own firmware and talking to the mobile network itself. The OS sees packets the modem hands it, not what the modem firmware does with radio signalling.

Data centres add SmartNICs and DPUs, which are full systems with their own cores and operating systems sitting in the data path. Our network card evolution post covers that history.

In every case the host firewall sits above the firmware and filters only what the driver passes up. The controls are the same as elsewhere: buy from makers who publish firmware updates, apply them, and inventory versions.

How out of band traffic bypasses host firewall rules

1. Dedicated BMC port. Traffic never touches the host. Only the network can filter it.
2. Shared BMC port through NC-SI. The network controller forwards matching frames to the BMC over the sideband; the host stack never receives them.
3. Intel AMT on wired Ethernet. Packets to AMT's ports go to the ME directly, so Windows Firewall rules on them have no effect.
4. Intel AMT on Wi-Fi. The host wireless driver relays AMT traffic, yet Intel still documents that the OS firewall does not block AMT ports.
5. Pre-boot network stacks. UEFI PXE or HTTP boot and NIC option ROMs run before the OS firewall exists.
6. Host side channels. The OS talks to the ME through MEI and to many BMCs through a host interface, so a compromised host with admin rights can be a route into the management plane, not only the other way round.

None of these are bugs; they are what out of band management is for. What you control is where those paths terminate and who can reach them.

What NSA and CISA recommend for BMCs

On 14 June 2023, NSA and CISA released a joint Cybersecurity Information Sheet, "Harden Baseboard Management Controllers." The PDF on the defence media site blocked our automated fetch, so the points below come from CISA's alert announcing it and from SecurityWeek's summary of the document. Check the PDF itself before you quote it in policy.

CISA's alert says hardened credentials, firmware updates and network segmentation are often overlooked, which leaves BMCs vulnerable, and urges every organisation that manages servers to apply the actions. The summarised recommendations are:

• Replace default BMC credentials with strong, unique passwords that follow NIST guidance.
• Put BMCs on a separate, isolated network or VLAN, and limit which systems can connect.
• Check routinely for BMC firmware updates, which often arrive separately, and apply them.
• Monitor BMC integrity, and favour platforms that support it.
• Treat an unused BMC as if it may one day be activated: harden its credentials and restrict access anyway.

That last point catches many teams: an unconfigured BMC still boots with the server, often keeps a factory account, and may pick up a DHCP address on a shared port.

What NIST SP 800-193 adds: protect, detect, recover

NIST SP 800-193, "Platform Firmware Resiliency Guidelines" (May 2018), is the framework most firmware security programmes map to. It organises guidance around three goals: protect platform firmware and critical data from unauthorised changes, detect when unauthorised changes happen, and recover rapidly and securely to a known good state.

It covers the BMC and ME explicitly, noting that "most modern server and client platforms include a BMC/ME" and that their firmware must not undermine the host's integrity. It defines roots of trust for update (signature checks on firmware updates), detection and recovery.

For a buyer, that means procurement questions: does the BMC verify signed updates, detect a corrupted image and recover from a golden copy? Those features come from the hardware maker; host software cannot add them later.

A hardening walkthrough you can run

These steps assume you administer the machines and networks involved. Scan only networks you own or are authorised to test. Configuration changes are marked; each can lock you out of a BMC, so keep console or physical access available.

Step 1: Inventory what management hardware exists

On Linux, check whether the host can see an Intel ME interface and what firmware tools report:

# Is there an MEI device node? (Intel ME present and driver loaded)
ls -l /dev/mei* 2>/dev/null

# List chipset functions that mention the management engine
lspci -nn | grep -i -E "mei|heci|management engine"

# Firmware devices and versions that fwupd knows about
fwupdmgr get-devices

# Platform firmware security checks, including ME state on Intel (fwupd 1.8.4 or later)
fwupdmgr security

# BIOS vendor, version and release date
sudo dmidecode -t bios

The fwupdmgr security output reports Host Security ID (HSI) attributes. On Intel systems it includes checks such as whether the ME is in manufacturing mode, whether the flash descriptor override strap is active, and whether the CSME version is affected by the 2017 CVEs.

On Windows, PowerShell can show whether the ME interface driver is present and what the host firewall is doing:

# Management Engine interface devices visible to Windows
Get-PnpDevice | Where-Object { $_.FriendlyName -match "Management Engine|MEI" } |
  Select-Object Status, FriendlyName, InstanceId

# Host firewall profiles and their state
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction

# BIOS version and date
Get-CimInstance Win32_BIOS | Select-Object Manufacturer, SMBIOSBIOSVersion, ReleaseDate

To see whether AMT is provisioned, use the Intel detection tool referenced in SA-00075 or your PC maker's tooling.

For servers, read the BMC firmware version from the BMC itself:

# Redfish: list managers (BMCs) and firmware inventory. Use a read only account.
BMC=https://bmc01.mgmt.example.internal
curl -s -u "$BMC_USER" "$BMC/redfish/v1/Managers" | jq '.Members[]."@odata.id"'
curl -s -u "$BMC_USER" "$BMC/redfish/v1/UpdateService/FirmwareInventory" | jq '.Members[]."@odata.id"'

# IPMI only BMCs: firmware revision
ipmitool -I lanplus -H bmc01.mgmt.example.internal -U "$IPMI_USER" -E mc info

The -E flag tells ipmitool to read the password from the IPMI_PASSWORD environment variable, which keeps it out of shell history. $BMC_USER in the curl lines can be user alone, in which case curl prompts for the password.

Step 2: Find management interfaces from the network side

Host side tools cannot tell you what the network can reach. Scan from the network, from a machine on each segment that matters, for the management ports covered above:

# TCP ports used by AMT, DASH, Redfish and BMC web UIs, SSH and VNC
nmap -Pn -sT -p 22,80,443,623,664,5900,16992-16995 --open 10.20.0.0/24

# IPMI over LAN listens on UDP 623
sudo nmap -sU -p 623 --open 10.20.0.0/24

Any BMC or AMT port answering on a production or user VLAN is a segmentation gap, and any answer on 16992 or 16994 means unencrypted AMT is present. Run the same scan against your public ranges from outside.

Step 3: Isolate the management network (configuration change)

The goal: only a few administrative jump hosts can reach BMC and AMT interfaces, and the management network can reach nothing else except time, logging and update servers. Put dedicated BMC ports on a management VLAN, set a VLAN tag on shared port BMCs, then enforce policy between segments. A minimal nftables example on a Linux router:

# /etc/nftables.d/mgmt.nft (illustrative; adapt addresses and interfaces)
table inet mgmt {
  set jump_hosts { type ipv4_addr; elements = { 10.10.5.10, 10.10.5.11 } }

  chain forward {
    type filter hook forward priority 0; policy drop;
    ct state established,related accept

    # Jump hosts may reach BMC HTTPS, SSH and AMT TLS ports on the management VLAN
    iifname "vlan10" oifname "vlan99" ip saddr @jump_hosts tcp dport { 22, 443, 16993, 16995, 664 } accept

    # Management VLAN may send logs and get time from the core services subnet
    iifname "vlan99" oifname "vlan20" ip daddr 10.20.1.0/24 udp dport { 123, 514 } accept
    iifname "vlan99" oifname "vlan20" ip daddr 10.20.1.0/24 tcp dport 6514 accept

    log prefix "mgmt-drop " counter drop
  }
}

Load it with sudo nft -c -f /etc/nftables.d/mgmt.nft first to check syntax, then without -c to apply. Leave out UDP 623 entirely unless you still need IPMI over LAN. Harden and log the jump hosts; they now hold the keys.

Step 4: Change BMC defaults and turn off what you do not use (configuration change)

List accounts on a Redfish BMC and look for factory accounts, shared names and unknown users:

curl -s -u "$BMC_USER" "$BMC/redfish/v1/AccountService/Accounts" | jq '.Members[]."@odata.id"'
curl -s -u "$BMC_USER" "$BMC/redfish/v1/AccountService/Accounts/2" | jq '{UserName, RoleId, Enabled, PasswordChangeRequired}'

Change a password through the account resource. Your BMC may require an ETag in an If-Match header; check its documentation.

read -rs NEWPW
curl -s -u "$BMC_ADMIN" -X PATCH -H "Content-Type: application/json" \
  -d "{\"Password\": \"$NEWPW\"}" \
  "$BMC/redfish/v1/AccountService/Accounts/2"
unset NEWPW

Then check which protocols the BMC exposes, and switch off those you do not need. IPMI over LAN, Telnet, plain HTTP and SSDP are the usual candidates:

# Replace 1 with your Manager ID from Step 1
curl -s -u "$BMC_USER" "$BMC/redfish/v1/Managers/1/NetworkProtocol" \
  | jq '{HTTP, HTTPS, IPMI, SSH, SNMP, Telnet, SSDP, KVMIP, VirtualMedia}'

# Disable IPMI over LAN (configuration change; confirm nothing still uses it)
curl -s -u "$BMC_ADMIN" -X PATCH -H "Content-Type: application/json" \
  -d '{"IPMI": {"ProtocolEnabled": false}}' \
  "$BMC/redfish/v1/Managers/1/NetworkProtocol"

ProtocolEnabled is part of DMTF's ManagerNetworkProtocol schema, but some makers implement only part of it or keep related settings under OEM extensions, so read the response and confirm the change with a second GET and a port scan. If you must keep IPMI, follow CISA's 2013 advice: disable cipher 0 and anonymous logins, use encryption, and restrict UDP 623 at the network. Cipher suite settings vary by BMC, so use your vendor's guide.

Finally, replace the BMC's default TLS certificate with one from your internal CA. The Redfish specification requires that implementations allow this.

Step 5: Disable or lock down Intel AMT if you do not use it (configuration change)

If nobody manages PCs through AMT, turn it off or unprovision it in firmware setup per your PC maker's documentation, then verify from the network:

nmap -Pn -sT -p 623,664,16992-16995 --open <pc-address>

You want no open ports. If you use AMT, provision it with TLS and strong credentials, require user consent for KVM sessions (Intel documents this option), restrict its ports to your management servers, and keep CSME firmware current.

Step 6: Put firmware on a patch schedule

Firmware updates come from several places, and each needs an owner:

• Server BMC and BIOS. From the server maker's support site or management tooling. Redfish UpdateService can apply updates on many BMCs.
• Intel CSME and AMT. Through the PC or server maker's BIOS or firmware packages, as Intel's advisories state.
• AMD platform firmware. Through the PC or motherboard maker's BIOS update, carrying the PI version AMD lists in its bulletin.
• NIC and storage controller firmware. From the card maker or server maker.
• Linux desktops and many laptops. fwupd and the Linux Vendor Firmware Service deliver updates for supported devices:

fwupdmgr refresh
fwupdmgr get-updates
sudo fwupdmgr update

An interrupted firmware update can brick a device, so use stable power and update one machine per model first. Watch Intel's Security Center and AMD's product security page; Intel's August 2026 release alone included chipset, UEFI and processor firmware advisories.

Step 7: Log BMC and management access

You cannot detect what you do not record. Most BMCs keep an event log and many can forward to syslog:

# Redfish: log services the BMC exposes
curl -s -u "$BMC_USER" "$BMC/redfish/v1/Managers/1/LogServices" | jq '.Members[]."@odata.id"'

# IPMI: system event log
ipmitool -I lanplus -H bmc01.mgmt.example.internal -U "$IPMI_USER" -E sel list

Forward BMC logs to your central log store. Alert on logins from non jump host addresses, new accounts, firmware updates outside change windows, virtual media mounts and remote console sessions. Watch the Step 3 drop log too.

Which control belongs at which layer?

The host firewall appears in one row. It is necessary, and far from enough.

What about laptops and small offices?

The same logic applies without a data centre. If your laptops are vPro business models, find out whether AMT is enabled and whether anyone uses it; if not, turn it off. A developer laptop is also part of your software supply chain, holding source, signing keys and tokens, so keep its firmware as current as a server's. Our posts on Secure Boot certificate rotation and hardware supply chain trust boundaries cover related ground.

Where Safeguard fits, honestly

Safeguard is a software supply chain security platform. It does not scan, monitor or protect firmware, BMCs, the Management Engine or network card firmware, it does not manage devices, and none of the hardening steps above depend on it. Those layers are patched by hardware makers and secured by network design.

The overlap is narrower. BMC images and firmware packages ship open source components such as web servers, TLS libraries and embedded Linux userlands. When a vendor gives you an SBOM for that software, Safeguard can analyse it (safeguard scan --sbom vendor-bmc-sbom.json), match its components against vulnerability databases, and show which of your products and projects contain a given component and version. That depends entirely on the vendor providing the SBOM. The larger fit is the software you build and run on these machines: the management scripts, automation, applications and container images in your own repositories, which Safeguard scans with the CLI or the local runner. See our post on finding affected products fast with SBOMs for that workflow.

Common mistakes

• Treating "firewall on" as "machine protected." The host firewall cannot see BMC, AMT or NIC firmware traffic. Intel says so in writing for AMT.
• Putting BMCs on the production VLAN. A shared port with no VLAN tag makes the BMC reachable by anything that can reach the server.
• Leaving factory credentials on a BMC nobody uses. NSA and CISA specifically say to treat an unused BMC as if it may one day be activated.
• Keeping IPMI over LAN on "for compatibility." If nothing uses it, disable it. If something does, restrict UDP 623 and disable cipher 0.
• Assuming Windows Update or apt covers firmware. CSME, AMD platform firmware and BMC images usually come from the hardware maker's channel.
• Scanning only from inside the management network. Scan from production and user segments, and from the internet, to see what is actually reachable.
• Not logging the management plane. BMC logins, account changes and virtual media mounts should land in the same log store as everything else.
• Forgetting the jump hosts. Isolating BMCs behind two admin hosts moves the risk to those hosts. Harden and monitor them.

FAQ

Can a firewall block Intel AMT?

A host firewall on the same PC cannot. Intel's own documentation says an operating system firewall will not block access to AMT ports, and that wired LAN messages to those ports go directly to AMT. A network firewall between the PC and other segments can block AMT ports, and disabling or unprovisioning AMT in firmware removes the service.

What ports does Intel AMT use?

Intel lists 16992 and 16993 (HTTP and HTTPS), 16994 and 16995 (redirection over TCP and TLS), 623 (ASF RMCP), 664 (DMTF secure management) and 5900 (VNC). The unencrypted 16992, 16994 and 623 are deprecated.

Does a BMC work when the server is turned off?

Yes. CISA's 2023 alert says BMCs can function even when a machine is powered off. With standby power, the BMC is running and reachable.

Is IPMI still safe to use?

CISA warned in 2013 about default passwords, cipher 0 authentication bypass and internet exposure. If you need IPMI, isolate it, disable cipher 0 and anonymous logins, and use unique passwords. Where Redfish over HTTPS is available, prefer it and disable IPMI over LAN.

What is the difference between a BMC and the Intel Management Engine?

NIST SP 800-193 describes both as out of band management devices. A BMC is a separate controller on a server board with its own network port or sideband. The ME is a coprocessor in Intel chipsets found in servers and client PCs; on vPro business PCs it runs AMT for remote management.

Can I remove or disable the Intel Management Engine?

You can usually disable AMT, the remote management feature, through firmware setup. The ME itself handles other platform functions and is not something PC makers support removing. Keeping its firmware updated through your PC maker is the supported control.

Does AMD have something like the Intel Management Engine?

AMD processors include the AMD Secure Processor, a security coprocessor with its own bootloader and firmware. AMD publishes vulnerabilities in it through AMD-SB bulletins and ships fixes as platform firmware that reaches you through your PC or motherboard maker's BIOS update. Business systems may also implement DMTF DASH for remote management.

How do I check if my BMC is exposed to the internet?

Scan your public IP ranges from outside your network for TCP 443, 22, 623 and 664 and UDP 623, and check which hosts answer with BMC banners or certificates. Only scan ranges you own. Any answer is a finding to fix by moving the BMC behind a management network.

Fix it without waiting for upstream

The firmware layers in this post are fixed by hardware makers, so the steps below do not patch a BMC or a Management Engine. They apply to the open source software you build and run on top of that hardware, including the automation and management tooling that talks to your BMCs, which is where most teams can close exposure fastest.

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

None of these demos touch firmware, a BMC or the Management Engine. They show the software side: the code and dependencies your team builds and runs on the hardware this post describes. If you want to try the CLI yourself, download it from https://safeguard.sh/download and read the setup guide at https://docs.safeguard.sh/docs/cli .

This first demo is a real CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repo, and 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 flow applies to the repositories that hold your infrastructure automation, such as the scripts and tools that call BMC APIs across a fleet.

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

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then scans from the terminal. For teams that keep management tooling on an isolated admin network, this is how scanning can run locally on a jump host or build machine without moving that code anywhere else.

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 you ingest a vendor's BMC or firmware SBOM, this lets you ask questions about its components in plain language, with access limited to the tools you allowed.

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

Quick check

Sources

• CISA: CISA and NSA Release Joint Guidance on Hardening Baseboard Management Controllers (BMCs), 14 June 2023
• SecurityWeek: CISA, NSA share guidance on hardening baseboard management controllers
• CISA: TA13-207A Risks of Using the Intelligent Platform Management Interface (IPMI)
• NIST SP 800-193: Platform Firmware Resiliency Guidelines
• NIST SP 800-193 PDF
• DMTF: Redfish Specification DSP0266 version 1.25.0
• DMTF: Redfish Developer Hub
• DMTF: ManagerNetworkProtocol schema v1.11.0
• DMTF: Network Controller Sideband Interface (NC-SI) Specification DSP0222 version 1.2.0
• Intel: Intel Active Management Technology and vPro privacy information
• Intel: AMT Implementation and Reference Guide, Manageability Ports
• Intel: INTEL-SA-00075
• Intel: INTEL-SA-00086
• Intel: INTEL-SA-01427
• Intel Product Security Center
• AMD: AMD-SB-4013, AMD Athlon and AMD Ryzen Processor Vulnerabilities, February 2026
• Microsoft Learn: Windows Firewall overview
• Linux kernel documentation: Intel Management Engine Interface (Intel MEI)
• fwupd: Host Security ID Specification

Last reviewed: 23 October 2026. Firmware advisories and BMC features change often; check the linked vendor and agency pages for the latest guidance.