Redfish Explained: DMTF's Server Management API and BMC Security

Redfish is the DMTF standard API for managing servers out of band: a RESTful HTTPS interface with a JSON data model, served by the baseboard management controller (BMC) on the motherboard. It covers inventory, power, firmware updates, accounts and attestation. To secure a BMC, isolate its network, turn off IPMI over LAN, use sessions and least privilege roles, replace certificates and verify every firmware image.

This guide goes one level deeper than our overview of what a firewall cannot see in firmware, BMCs and management engines and our look at BMC firmware as a supply chain problem. Here we read the Redfish specification itself, DSP0266 version 1.25.0 published on 7 August 2026, alongside the published Redfish JSON schemas (release 2026.2), the SPDM specification, the OpenBMC project's own documentation and the June 2023 NSA and CISA guidance on hardening BMCs. Every endpoint, property and default below comes from those documents. Where a behaviour depends on the vendor's implementation, we say so.

Key takeaways

• A BMC is a separate computer inside the server. It runs as soon as power is applied, sits outside the operating system's controls, and can reflash firmware, mount virtual media and reboot the host. NSA and CISA say endpoint tools and TPM attestation do not mitigate a compromised BMC.
• Redfish (first published as DSP0266 1.0.0 on 4 August 2015) replaces IPMI's binary UDP protocol with HTTPS, JSON and a versioned schema. The tree starts at /redfish/v1/ and branches into Systems, Chassis, Managers, AccountService, SessionService, UpdateService, CertificateService and ComponentIntegrity.
• The specification requires services to support both HTTP Basic authentication and session login, requires TLS 1.2 or later for Basic auth, and defines three mandatory roles (Administrator, Operator, ReadOnly) built from five standard privileges.
• The classic IPMI weaknesses were structural: RAKP lets a remote client obtain a password hash for offline guessing, and "cipher 0" let some devices skip authentication. The fix is to disable IPMI over LAN where you can, and to keep the management network unreachable where you cannot.
• Redfish UpdateService can pull an image from a URL (SimpleUpdate) or accept a pushed image (MultipartHttpPushUri). Image signing and verification are implementation details. OpenBMC builds sign images with a development key by default, so production builds must supply their own key.
• SPDM and the Redfish ComponentIntegrity resource let a BMC report signed firmware measurements from devices such as NICs and GPUs, and a Redfish client can ask for a fresh, nonce bound signed measurement.

What is a BMC, and why did Redfish replace IPMI over LAN?

The BMC in one paragraph

The Redfish specification defines a baseboard management controller as "typically, an independent microprocessor or system-on-chip with associated firmware" that performs out of band monitoring and management. The NSA and CISA Cybersecurity Information Sheet (CSI) from June 2023 adds the part that matters for security: BMC firmware "is highly privileged, executes outside the scope of operating system (OS) controls, and has access to all resources of the server-class platform." It starts when power is applied, so the host does not need to be booted, or even switched on, for the BMC to work.

In practice a BMC gives an administrator a remote power button, a remote keyboard, video and mouse (KVM over IP), virtual media that the host sees as a USB drive, sensor readings, event logs and a way to flash BIOS, BMC and often peripheral firmware. That is exactly why the agencies treat it as a high value target. The CSI lists what an attacker on a vulnerable BMC can do: establish a foothold "with pre-boot execution potential", disable TPM or UEFI Secure Boot, manipulate data on attached storage and spread implants across the network. It also states that endpoint detection and response, intrusion prevention, anti-malware suites, kernel hardening, virtualization features and TPM attestation "are ineffective at mitigating a compromised BMC." For background on where the BMC sits on the board, see our motherboard evolution post covering chipsets, BIOS, UEFI, TPM and the BMC.

Why IPMI aged badly

The Intelligent Platform Management Interface was the dominant BMC interface for years, and the Redfish schema still models it: the ManagerNetworkProtocol resource has an IPMI object for "IPMI-over-LAN protocol support", and the schema notes the default port "should be 623 for compatibility with established client implementations."

CISA's 2013 alert on IPMI risks, still available in its archive, captures why the protocol became a liability. Among the issues it lists: IPMI passwords were saved in clear text on many BMCs, knowledge of one IPMI password could unlock every machine in a managed group, BMCs ran "excess and older network services", some traffic was not encrypted, and there were few tools to detect a compromised BMC. Its advice was to restrict IPMI traffic, usually on UDP port 623, to a management VLAN, set strong unique passwords, enable encryption where possible, disable cipher 0 and anonymous logins, and in the worst case physically destroy the flash chip if a vendor gave no way to sanitize stored passwords.

The deeper problem was design age. IPMI is a binary protocol over UDP with its own session and cipher negotiation, which made it hard to inspect with ordinary web tooling, hard to extend, and hard to secure without breaking compatibility.

What Redfish changed

DMTF's Redfish Forum set out to build something that ordinary web and cloud tooling could use. DSP0266 describes Redfish as "a standard that uses RESTful interface semantics to access a schema-based data model," aimed primarily at "large and hyperscale environments" but usable for a single server. The design tenets in the specification include a JSON payload, separation of protocol from data model, explicit versioning rules for both, and reliance on existing standards such as HTTP, TLS, OData and OpenAPI.

A precise note on the word "replace": the Redfish specification does not deprecate IPMI, and many BMCs still ship both. Redfish replaced IPMI in the sense that new management features (component attestation, multi factor authentication, certificate management, telemetry) land in Redfish, and the security model of HTTPS plus sessions is far easier to reason about. IPMI over LAN remains a legacy option you should switch off unless a tool you cannot replace depends on it.

Timeline

IPMI over LAN versus Redfish

How is the Redfish data model organised?

Everything starts at the service root. The specification lists a small set of resources that must be readable without authentication: the service root itself, the $metadata document, the OData service document, the OpenAPI YAML document and the version object at /redfish. Everything else needs credentials.

# The version object and the service root. Neither needs credentials.
curl -s --cacert /etc/pki/bmc/ca.pem https://bmc01.mgmt.example.internal/redfish
curl -s --cacert /etc/pki/bmc/ca.pem https://bmc01.mgmt.example.internal/redfish/v1/ | jq .

A trimmed service root looks like this:

{
  "@odata.id": "/redfish/v1/",
  "@odata.type": "#ServiceRoot.v1_17_0.ServiceRoot",
  "RedfishVersion": "1.17.0",
  "UUID": "92384634-2938-2342-8820-489239905423",
  "Systems": { "@odata.id": "/redfish/v1/Systems" },
  "Chassis": { "@odata.id": "/redfish/v1/Chassis" },
  "Managers": { "@odata.id": "/redfish/v1/Managers" },
  "AccountService": { "@odata.id": "/redfish/v1/AccountService" },
  "SessionService": { "@odata.id": "/redfish/v1/SessionService" },
  "UpdateService": { "@odata.id": "/redfish/v1/UpdateService" },
  "CertificateService": { "@odata.id": "/redfish/v1/CertificateService" },
  "ComponentIntegrity": { "@odata.id": "/redfish/v1/ComponentIntegrity" },
  "Links": { "Sessions": { "@odata.id": "/redfish/v1/SessionService/Sessions" } }
}

The ServiceRoot schema (v1.22.0 in release 2026.2) defines many more links, including EventService, TelemetryService, Tasks, Registries, JsonSchemas, Fabrics, Storage, KeyService, LicenseService and, since v1.22.0, PolicyService. A given BMC exposes only what it implements.

The resources that matter for operations and security

Two rules from the specification shape how clients should treat this tree. First, URIs of collection members are not fixed: the OpenBMC Redfish cheat sheet quotes DSP0266 directly, "Clients shall not make assumptions about the URIs for the members of a resource collection." Always follow @odata.id links instead of hard coding /Managers/1 or /Managers/bmc. Second, every resource carries @odata.type with a versioned schema name such as #Manager.v1_25_0.Manager, so a client can tell exactly which properties may appear.

The schemas are published as DSP8010 (the schema bundle), with DSP0268 as the human readable data model reference and DSP8011 holding the message registries. You can browse the JSON Schema files directly at redfish.dmtf.org/schemas/v1/.

How do sessions, Basic auth, roles and privileges work?

Two required ways to log in

DSP0266 clause 13.3 says services "shall support both HTTP Basic authentication and Redfish session login authentication." It also says services should reject a request that carries more than one authentication method, and that services must not use HTTP cookies to authenticate Redfish operations.

HTTP Basic sends the username and password with every request. The specification requires HTTPS for every Basic request, notes that the IETF has highlighted security concerns with Basic authentication, and gives administrators a switch: the HTTPBasicAuth property on AccountService (added in v1.15.0) accepts Enabled, Unadvertised (still works but is not advertised in the WWW-Authenticate header) or Disabled. The schema says it "should default to Enabled for client compatibility." When multi factor authentication is enabled, the service must reject Basic auth for accounts that do not bypass MFA.

Session login is the recommended path. The client sends a POST with UserName and Password to the Sessions collection, which must only be accepted over HTTPS. The service returns 201 Created with two headers: X-Auth-Token, the secret the client sends on every later request, and Location, the URI of the new Session resource. The session ID in that URI is not the token. An administrator can list sessions and delete any of them by ID, but only the client that logged in holds the token.

Sessions time out on inactivity rather than at a fixed expiry. The SessionService SessionTimeout property is expressed in seconds, with a schema minimum of 30 and maximum of 86,400 (24 hours). If the account behind a session is deleted, disabled or locked, the service should end all its sessions. Logging out is a DELETE on the Session resource.

# Create a session without putting the password on the command line.
export BMC=bmc01.mgmt.example.internal
export CA=/etc/pki/bmc/ca.pem
export RF_USER=svc-inventory
read -r -s -p "BMC password: " RF_PASS; echo; export RF_PASS

jq -n '{UserName: env.RF_USER, Password: env.RF_PASS}' |
  curl -s --cacert "$CA" -D headers.txt -o /dev/null \
       -H "Content-Type: application/json" \
       -X POST "https://$BMC/redfish/v1/SessionService/Sessions" -d @-

TOKEN=$(awk 'tolower($1)=="x-auth-token:" {print $2}' headers.txt | tr -d '\r')
SESSION=$(awk 'tolower($1)=="location:" {print $2}' headers.txt | tr -d '\r')
unset RF_PASS; rm -f headers.txt

# Use the token
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/Managers" | jq .

# Log out when finished
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" -X DELETE "https://$BMC$SESSION"

Notice what this snippet avoids. It does not pass the password as a command line argument, where other users on the host could read it from the process list, and it pins the BMC's CA certificate rather than turning off certificate checks. Many vendor and community examples, including the OpenBMC cheat sheet, use curl's insecure mode for brevity on lab systems. That is fine on a bench and wrong in production.

Client certificates and external identity

Clause 13.3.5 covers client certificate authentication, including mutual TLS and smart cards (CAC or PIV). When enabled, the service requests a client certificate during the TLS handshake, verifies it against the certificates configured under the AccountService multi factor settings, and checks revocation with any configured OCSP servers. The AccountService schema also defines LDAP, Active Directory, TACACS+ and OAuth 2.0 providers, plus RemoteRoleMapping to map directory groups to local roles. The NSA and CISA CSI points out that most BMCs historically did not integrate with central account management, so check what your hardware actually supports before you plan around a directory.

Roles and privileges

Authorization in Redfish has two parts: a privilege model that maps users to roles and roles to privileges, and an operation to privilege mapping that says which privileges each HTTP operation on each resource requires. Each manager account has exactly one role, set by RoleId.

ConfigureSelf lets an account change its own password. ConfigureComponents covers actions on the managed host, such as resets. ConfigureManager covers BMC settings, including network protocols and firmware updates, and ConfigureUsers covers account management. The standard roles' privilege lists cannot be modified, and services may let clients create custom roles with a POST to the Roles collection.

Two newer features are worth knowing. Restricted roles and privileges exist "to prevent privilege escalation": a service can mark a role as restricted so an administrator cannot assign it to any account, including their own, which lets a platform keep a security officer role out of the ordinary administrator's reach. The privilege map (PrivilegeMap on AccountService) publishes the operation to privilege mapping, including overrides for specific properties or URIs, so you can audit exactly what an Operator can do on your hardware rather than guessing.

The specification also says non Redfish services on an account, such as SSH, should map the Redfish role to their own permissions, for example Administrator to root, so a Redfish role can unlock more than Redfish.

What were the classic IPMI weaknesses, and what replaced them?

This section describes the mechanisms conceptually so you can judge your own exposure. It does not explain how to exploit them.

RAKP hash disclosure

IPMI 2.0 authenticates remote sessions with RMCP+ and the RAKP key exchange. The NVD entry for CVE-2013-4786, published on 8 July 2013, summarises the problem: the protocol "allows remote attackers to obtain password hashes and conduct offline password guessing attacks by obtaining the HMAC from a RAKP message 2 response from a BMC." In plain terms, the BMC proves its knowledge of the user's password by sending a keyed hash early in the handshake, before the client has proved anything. Anyone who can reach UDP 623 and guess a valid username can collect that value and attack it offline, where no lockout policy applies.

Because this behaviour is part of the specification rather than a coding error, no firmware patch removes it while keeping IPMI 2.0 compatible. The mitigations are all about reach and strength: block UDP 623 from everything except a management jump host, disable IPMI over LAN entirely if you can, use long random passwords that make offline guessing impractical, and do not reuse BMC passwords across machines.

Cipher 0 and anonymous access

CISA's 2013 alert describes "cipher 0" as an option enabled by default on many IPMI devices "that allows authentication to be bypassed." Cipher suite 0 negotiates no authentication, no integrity and no confidentiality. Combined with anonymous or null user accounts that some devices shipped with, it let a remote client issue IPMI commands without valid credentials. CISA's advice was to disable cipher 0 and anonymous logins.

Cleartext credential storage and shared passwords

The same alert notes that IPMI passwords were stored in clear text on many BMCs and that one IPMI password often opened every machine in a group. The RAKP exchange requires the BMC to know the plain password (or an equivalent) to compute its proof, which pushes implementations toward reversible storage. That is why a single compromised BMC so often led to many.

What replaced them

None of these replacements helps while IPMI over LAN is still enabled next to Redfish. The old protocol's weaknesses remain reachable on port 623 regardless of how well the HTTPS side is configured.

How does Redfish UpdateService push firmware, and how should images be verified?

Two update models

DSP0266 clause 12.7 defines two ways to deliver an image:

1. Simple updates (pull). The client POSTs to the SimpleUpdate action with an ImageURI, and the BMC fetches the image itself. The schema's TransferProtocol values include HTTP, HTTPS, SCP, SFTP, FTP, TFTP, CIFS, NFS and OEM. Optional parameters include Targets, ExcludeTargets, Username, Password, Stage, LocalImage and ForceUpdate. The service should return 202 Accepted with a task monitor URI.
2. Multipart HTTP push. The client POSTs a multipart/form-data body to the URI advertised in MultipartHttpPushUri. The body must contain exactly one JSON part named UpdateParameters (targets and options such as @Redfish.OperationApplyTime) and one binary part named UpdateFile. Access requires the same privilege as the update service. A service may advertise MaxImageSizeBytes and should return 413 for oversized images. The older, vendor formatted HttpPushUri still exists in the schema.

The @Redfish.OperationApplyTime annotation lets you stage an update to apply Immediate, OnReset or on an explicit StartUpdate request, so you can push images during the day and activate them in a maintenance window.

What the standard says about trust, and what it leaves to you

The UpdateService schema gives administrators several controls for the pull model:

• VerifyRemoteServerCertificate and the RemoteServerCertificates collection, so the BMC checks the TLS certificate of the server named in ImageURI against certificates you load.
• VerifyRemoteServerSSHKey and RemoteServerSSHKeys for SCP and SFTP sources, and PublicIdentitySSHKey for key based authentication of the BMC to the image server.
• ClientCertificates for presenting a client identity to the image server.
• ForceUpdate, which the schema says lets the service "bypass update policies when applying the provided image, such as allowing a component to be downgraded," while noting services may keep policies that can never be bypassed, such as minimum version enforcement.

What the Redfish standard does not define is the image signature format or the verification algorithm. That belongs to the firmware and hardware: the BMC's update agent, the hardware root of trust, and the vendor's signing infrastructure. Transport checks only prove the image came from your server. Signature checks prove it came from the vendor and was not altered. You want both.

NIST SP 800-193, Platform Firmware Resiliency Guidelines (May 2018), frames the goal as three properties: protecting platform firmware against unauthorized changes, detecting unauthorized changes that occur, and recovering rapidly and securely. Applied to BMC updates, that means:

• Protection: the update path accepts only images signed by the platform vendor's key, verified by code the image itself cannot replace, with rollback protection so an old, vulnerable but validly signed image cannot be reinstalled. Treat ForceUpdate as a privileged exception and alert on its use.
• Detection: firmware inventory and integrity measurements are checked against known good values after every change, not just at purchase.
• Recovery: a known good image can be restored without trusting the running firmware, for example from a protected golden copy.

How OpenBMC signs and checks images

OpenBMC's documentation shows one concrete implementation. A BMC image tarball contains the U-Boot, kernel, read only and read write partitions plus a MANIFEST file with fields such as purpose, version, KeyType, HashType and MachineName. The update service compares MachineName with the machine the running image was built for and refuses to upgrade on a mismatch. The phosphor-bmc-code-mgmt build options include verify-signature (enabled by default) with signature files ending in .sig and public keys under /etc/activationdata/.

The build side is the part teams miss. In the OpenBMC Yocto class that packages images, SIGNING_KEY defaults to a key called OpenBMC.priv supplied by a recipe named phosphor-insecure-signing-key-native, and the class marks that case with an INSECURE_KEY flag. Each image file is signed with openssl dgst -sha256 -sign, and the signatures are combined into a signed image-full. If you build your own OpenBMC and never override SIGNING_KEY (or supply SIGNING_PUBLIC_KEY with signing done elsewhere), your images are signed with a key that anyone can download. Signature verification then proves nothing.

A push update with Redfish, done carefully

Warning: a firmware update rewrites flash on the target. A wrong image, a wrong target or a power loss can leave the BMC or host unbootable. Confirm the device identity first, keep a recovery path, and run updates in a maintenance window.

Step 1, confirm you are talking to the machine you think you are. Compare the service UUID and the chassis serial number against your inventory before every update block.

curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/" | jq -r .UUID
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/Chassis" \
  | jq -r '.Members[]."@odata.id"' \
  | while read -r c; do
      curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC$c" | jq -r '[.Id, .SerialNumber, .Model] | @tsv'
    done
# Stop here unless UUID and serial match the change ticket.

Step 2, verify the image before it leaves your hands. Check the vendor's published digest or signature with the vendor's documented method, and record the digest in the change ticket.

sha256sum bmc-firmware-2.18.4.tar

Step 3, read the update service and find the push URI and current versions.

curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/UpdateService" \
  | jq '{MultipartHttpPushUri, MaxImageSizeBytes, VerifyRemoteServerCertificate}'
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/UpdateService/FirmwareInventory?\$expand=.(\$levels=1)" \
  | jq -r '.Members[] | [.Id, .Version, (.Updateable|tostring)] | @tsv'

Not every BMC supports $expand. If yours does not, follow each member link in turn.

Step 4, push the image with an apply time of OnReset, re-checking identity immediately before.

URI=$(curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/UpdateService" | jq -r .MultipartHttpPushUri)
MGR=$(curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/Managers" | jq -r '.Members[0]."@odata.id"')

curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" -X POST "https://$BMC$URI" \
  -F "UpdateParameters={\"Targets\":[\"$MGR\"],\"@Redfish.OperationApplyTime\":\"OnReset\"};type=application/json" \
  -F "UpdateFile=@bmc-firmware-2.18.4.tar;type=application/octet-stream" -D - | grep -i '^location'

Step 5, follow the task monitor from the Location header until it completes, then confirm the new version in FirmwareInventory after the reset. Check the event log for any signature or compatibility rejection.

What does OpenBMC look like as an open source BMC stack?

OpenBMC describes itself as a Linux Foundation project producing "a customizable, open-source firmware stack" for BMCs, and as "a Linux distribution for management controllers used in devices such as servers, top of rack switches or RAID appliances." It is built with Yocto and OpenEmbedded, uses systemd for services and D-Bus as the internal object model.

The pieces

• The Yocto build produces a full flash image: bootloader, Linux kernel, a read only root file system and a writable partition.
• D-Bus services model sensors, inventory, software versions, users, logging and power control. Each hardware function is a D-Bus object.
• bmcweb is the embedded web server. Its README calls it a "do everything" server that provides a protocol compliant D-Bus to Redfish translator, a D-Bus REST API, a serial console over websockets and a KVM websocket. It supports HTTP/1 and HTTP/2 over TLS via OpenSSL.
• webui-vue is the browser interface that talks to bmcweb.
• phosphor-bmc-code-mgmt manages firmware images and activation, including the signature checks above.

bmcweb's authentication and authorization

bmcweb supports Basic authentication per RFC 7617, cookie based authentication for the web UI, mutual TLS, session authentication for the web UI and X-Auth-Token authentication conformant with DSP0266. Each can be enabled or disabled at build time or at runtime through Redfish. Username and password checks route through PAM. Authorization is decided at routing time per route and "conforms to the Redfish PrivilegeRegistry", with non Redfish functions mapped to the closest Redfish privilege.

The cookie path is for the browser UI. The Redfish specification forbids cookies as an authentication mechanism for Redfish operations, which is one reason automated clients should always use tokens or certificates.

How an OpenBMC image is built

From the project README:

# Ubuntu build host prerequisites (see the Yocto docs for the current list)
sudo apt install git gcc g++ make file wget gawk diffstat bzip2 cpio chrpath zstd lz4

git clone https://github.com/openbmc/openbmc
cd openbmc
. setup romulus            # pick your machine; run ". setup" alone to list targets
bitbake obmc-phosphor-image

Images land in tmp/deploy/images/<platform>/ as .ubi.mtd.tar or .static.mtd.tar tarballs. Before any build leaves a lab, set your own signing key in the machine or distro configuration so the INSECURE_KEY path is not taken. Commits are tested in CI against a QEMU model of the BMC using the openbmc-test-automation Robot Framework suite, which is also a good starting point for your own regression tests.

To build bmcweb alone for development, its README uses Meson:

meson setup builddir
ninja -C builddir

Why an open BMC stack matters for supply chain risk

A BMC image is an embedded Linux distribution with a kernel, a C library, OpenSSL, a web server and dozens of other open source packages. Whether it is built from OpenBMC or by a vendor from a proprietary tree, it carries the same dependency questions as any other software: which versions are inside, which have known vulnerabilities, and how quickly fixed builds reach your racks. The NSA and CISA CSI makes the operational point bluntly: "OS patch maintenance solutions do not deliver BMC updates." BMC updates follow their own path, so they need their own schedule.

How do you inventory and lock down BMCs with curl and Redfish?

The commands below assume the session from earlier and a read only service account for the inventory steps. Write steps need an account with ConfigureManager and, for accounts, ConfigureUsers. Implementations vary, so read before you write and expect some properties to be absent or read only on your hardware.

Step 1: build an inventory of every BMC

#!/usr/bin/env bash
# bmc-inventory.sh: one line per BMC, from a list of management hostnames.
set -euo pipefail
CA=/etc/pki/bmc/ca.pem
while read -r BMC; do
  root=$(curl -s -m 10 --cacert "$CA" "https://$BMC/redfish/v1/") || { echo "$BMC	unreachable"; continue; }
  ver=$(jq -r '.RedfishVersion // "unknown"' <<<"$root")
  uuid=$(jq -r '.UUID // "unknown"' <<<"$root")
  printf '%s\t%s\t%s\n' "$BMC" "$ver" "$uuid"
done < bmc-hosts.txt

The service root is readable without authentication, so this first pass needs no credentials. Then, with a session, collect the firmware version and network protocols for each manager:

for m in $(curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/Managers" | jq -r '.Members[]."@odata.id"'); do
  curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC$m" | jq '{Id, ManagerType, FirmwareVersion, Model}'
  curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC$m/NetworkProtocol" \
    | jq '{IPMI, HTTP, HTTPS, SSH, SSDP, Telnet, KVMIP, VirtualMedia, SNMP}'
done

Step 2: turn off IPMI over LAN and plaintext protocols

The ManagerNetworkProtocol resource exposes each protocol as an object with ProtocolEnabled and Port. Disabling IPMI over LAN is a single PATCH where the implementation allows it:

NP="$m/NetworkProtocol"
ETAG=$(curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" -D - -o /dev/null "https://$BMC$NP" | awk 'tolower($1)=="etag:" {print $2}' | tr -d '\r')
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" -H "Content-Type: application/json" \
     -H "If-Match: $ETAG" -X PATCH "https://$BMC$NP" \
     -d '{"IPMI": {"ProtocolEnabled": false}, "HTTP": {"ProtocolEnabled": false}, "SSDP": {"ProtocolEnabled": false}}'

Sending If-Match with the ETag you just read avoids overwriting a concurrent change, and some services require it. Leave HTTP disabled so the BMC answers only on HTTPS. SSDP and mDNS advertise the service on the local network; turn them off unless your provisioning relies on discovery. Telnet, FTP and plain SNMP versions without authentication should be off if the BMC offers them at all. Check VirtualMedia and KVMIP too: they are legitimate tools but powerful ones, and you may want them enabled only during break glass sessions.

After the PATCH, verify from outside. From a host on the management network, a UDP probe of port 623 should get no IPMI response, and port 80 should be closed.

Step 3: rotate and minimise accounts

List accounts and look for default names, unused accounts and anything with the Administrator role that is not a named person or a vaulted break glass account:

for a in $(curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/AccountService/Accounts" | jq -r '.Members[]."@odata.id"'); do
  curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC$a" | jq -c '{UserName, RoleId, Enabled, Locked, AccountTypes, PasswordChangeRequired}'
done

Then set the account policy. These AccountService properties are all defined in the schema; support varies:

curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" -H "Content-Type: application/json" -X PATCH \
  "https://$BMC/redfish/v1/AccountService" \
  -d '{"MinPasswordLength": 16, "AccountLockoutThreshold": 5, "AccountLockoutDuration": 900,
       "AccountLockoutCounterResetAfter": 900, "HTTPBasicAuth": "Disabled"}'

Disabling Basic auth forces clients onto sessions or certificates, which keeps the password off every request. Test your automation first, because some tools still default to Basic.

Rotate passwords from a vault, one unique random password per BMC. Change a password with a PATCH of Password on the account, or with the ChangePassword action where RequireChangePasswordAction is true. Create a dedicated ReadOnly account for monitoring and inventory so routine scripts never hold administrator credentials.

Step 4: replace the self signed certificate

DSP0266 requires that implementations "support replacement of the default certificate if one is provided" and use X.509 v3 certificates. The CertificateService offers GenerateCSR (the private key stays on the BMC) and ReplaceCertificate:

# Find where certificates live
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/CertificateService/CertificateLocations" | jq .

# Ask the BMC for a CSR; the certificate collection URI comes from the manager's NetworkProtocol HTTPS settings
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" -H "Content-Type: application/json" -X POST \
  "https://$BMC/redfish/v1/CertificateService/Actions/CertificateService.GenerateCSR" \
  -d "{\"CertificateCollection\": {\"@odata.id\": \"$m/NetworkProtocol/HTTPS/Certificates\"},
       \"CommonName\": \"$BMC\", \"AlternativeNames\": [\"$BMC\"], \"KeyPairAlgorithm\": \"TPM_ALG_ECDSA\",
       \"KeyCurveId\": \"TPM_ECC_NIST_P384\", \"Country\": \"US\", \"State\": \"CA\", \"City\": \"SF\",
       \"Organization\": \"Example\", \"OrganizationalUnit\": \"Infra\"}" | jq -r .CSRString > "$BMC.csr"

Sign the CSR with your internal management CA, then install it with ReplaceCertificate. Once every BMC presents a certificate from that CA, every client can use the CA file shown in these examples instead of skipping verification. Required CSR fields and supported key algorithms differ between implementations, so check the action's @Redfish.ActionInfo first.

Step 5: isolate the network

No API setting substitutes for this. Put BMC ports on a dedicated management VLAN, allow inbound connections only from jump hosts and management servers, block BMC access to the internet, and allow outbound traffic only to your update server, NTP, syslog and directory. If a BMC needs internet access for updates, the CSI recommends allowing only update traffic, and only during the download. Check shared NIC modes too: some servers can expose the BMC on a host data port, which puts it on a network you did not plan for.

Step 6: forward events and logs

Create an EventService subscription to your collector, or pull LogServices entries on a schedule, so failed logins, account changes, firmware updates and certificate changes reach the same place as your other security logs. The AccountService AuthFailureLoggingThreshold controls how many authorization failures per account occur before one is logged.

Step 7: check conformance

DMTF publishes two Python tools that only perform GET requests, so they are safe to run against production:

pip install redfish_service_validator redfish_interop_validator
# Schema conformance of the whole service
python RedfishServiceValidator.py -r https://bmc01.mgmt.example.internal -u svc-inventory -p "$RF_PASS"
# Conformance against an interoperability profile you write for your fleet
rf_interop_validator -r https://bmc01.mgmt.example.internal -u svc-inventory -p "$RF_PASS" MyFleetProfile.v1_0_0.json

The Service Validator also accepts a config.ini file, which keeps the password out of shell history. An interoperability profile can state that your fleet requires, for example, IPMI.ProtocolEnabled to be supported and writable, HTTPBasicAuth to exist and ComponentIntegrity to be implemented, which turns hardening requirements into a procurement check.

Hardening decision table

What did CISA and NSA publish about BMC hardening?

The joint NSA and CISA Cybersecurity Information Sheet "Harden Baseboard Management Controllers" was released on 14 June 2023 (version 1.0, marked TLP:CLEAR). CISA's announcement said "hardened credentials, firmware updates, and network segmentation options are often overlooked, leading to a vulnerable BMC." The CSI's recommended actions, which it aligns with the CISA and NIST Cross-Sector Cybersecurity Performance Goals, are:

1. Protect BMC credentials. Change default credentials as soon as possible, create unique administrator accounts where supported, use strong passwords that follow NIST SP 800-63B, and never expose default credentials to the internet or an untrusted segment.
2. Enforce VLAN separation. Isolate BMC connections on an administrative VLAN, limit which endpoints can reach them, and limit or block internet access, allowing only update traffic during downloads if updates need it.
3. Harden configurations. Follow vendor hardening guides; UEFI hardening guidance may apply to many BMC settings.
4. Perform routine BMC update checks. Check monthly or quarterly, and combine installation with scheduled maintenance. Some servers need a restart after a BMC update; some can restart the BMC on its own.
5. Monitor BMC integrity. Some BMCs report integrity data to a root of trust such as a TPM, a dedicated security chip or a CPU secure enclave. Monitor for unexpected changes.
6. Move sensitive workloads to hardened devices. Older hardware may have no BMC integrity monitoring, and a TPM alone does not guarantee BMC integrity data is collected.
7. Use firmware scanning tools periodically. Collect and inspect BMC firmware for integrity and unexpected changes on a schedule.
8. Do not ignore BMCs. Treat an unused BMC as if it may one day be activated: patch it, harden its credentials and restrict its network access.

Mapped to Redfish, items 1 and 2 are the AccountService and network steps above, item 4 is a FirmwareInventory comparison against vendor releases, and item 5 is where ComponentIntegrity and SPDM come in. Item 8 is the one teams skip most: a server with no cable in the BMC port today still has a BMC with factory credentials, and someone may plug it in during a rack move.

How do SPDM and component attestation via Redfish fit?

SPDM in brief

The Security Protocol and Data Model, DMTF DSP0274, defines messages for "authentication and provisioning of hardware identities, measurement for firmware and/or hardware identities, session key exchange protocols" and more. Version 1.4.1, published on 26 June 2026, states that SPDM supports both traditional and post quantum cryptography algorithms for signatures and authenticated key exchange.

The model has a Requester and a Responder. In a server, the BMC (or a platform root of trust) is usually the Requester, and devices such as network adapters, GPUs, storage controllers and accelerators are Responders. The flow, conceptually:

1. The Requester negotiates versions, capabilities and algorithms.
2. It retrieves the device's certificate chain, which ties a device identity key to the manufacturer.
3. It challenges the device to prove it holds the private key, using a fresh nonce so the answer cannot be replayed.
4. It requests measurements: hashes of firmware, configuration or a manifest, signed by the device's key. SPDM defines measurement blocks, a DMTF measurement format and a measurement extension log for hash extend style measurements.
5. Optionally it opens a secure session with encryption and integrity for later messages, with mutual authentication if the Requester also presents a certificate.

How Redfish exposes it

The ComponentIntegrity collection at the service root (added in ServiceRoot v1.13.0) holds one resource per component the platform can attest. Each resource has a ComponentIntegrityType of SPDM, TPM, TCM, TPCM or OEM, the type version, a TargetComponentURI pointing to the device in the Redfish tree, LastUpdated, and an SPDM object with what the Requester learned: identity, certificate details, communication and measurement data, and a verification status.

The SPDMGetSignedMeasurements action lets a Redfish client ask for a fresh signed statement. The schema says the action "generates an SPDM cryptographic signed statement over the given nonce and measurements of the SPDM Responder," with the Requester issuing SPDM GET_MEASUREMENTS requests for the indices asked for. A matching TPMGetSignedMeasurements action covers TPM 2.0 PCRs.

# What can this platform attest?
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/ComponentIntegrity" | jq -r '.Members[]."@odata.id"'

# Read one entry: type, target and verification status
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" "https://$BMC/redfish/v1/ComponentIntegrity/$ID" \
  | jq '{ComponentIntegrityType, ComponentIntegrityTypeVersion, TargetComponentURI, LastUpdated, SPDM}'

# Ask for fresh signed measurements bound to your own nonce
NONCE=$(openssl rand -hex 32)
curl -s --cacert "$CA" -H "X-Auth-Token: $TOKEN" -H "Content-Type: application/json" -X POST \
  "https://$BMC/redfish/v1/ComponentIntegrity/$ID/Actions/ComponentIntegrity.SPDMGetSignedMeasurements" \
  -d "{\"Nonce\": \"$NONCE\"}" | jq .

The response carries the signed measurement data and a reference to the certificate used to sign it. Your verifier then checks the signature against the device's certificate chain, checks the chain against the manufacturer's root, confirms the nonce matches, and compares the measurements against reference values for the firmware version you expect.

What attestation does and does not tell you

Attestation tells you which firmware a device says it is running, signed by a key the manufacturer certified. It is strong evidence against tampering in transit or in the supply chain between factory and rack. It does not tell you whether that firmware is vulnerable: a validly signed, unmodified image can still contain an outdated library. It also depends on reference values. If you do not know what the correct measurements are for each firmware version, a valid signature over an unknown hash only tells you the device is consistent, not that it is correct.

It also has a trust ordering problem that matters here. The BMC is usually the Requester. If the BMC itself is compromised, its reports about other components are only as trustworthy as the BMC. That is why platform designs pair SPDM with a hardware root of trust that measures the BMC before it runs, and why the NSA and CISA CSI recommends moving sensitive workloads to hardware "designed to audit both the BMC firmware and the platform firmware."

Common mistakes

• Leaving IPMI over LAN on because Redfish is "the new interface". Port 623 stays exposed with all its old weaknesses. Disable it, then verify from the network.
• Running production scripts with certificate checks turned off. Lab examples skip verification for brevity. In production that lets anyone on the path impersonate the BMC and collect credentials. Replace certificates and pin your CA.
• Passing passwords on the command line. Arguments show up in process listings and shell history. Use environment variables read silently, config files with tight permissions, or a vault helper.
• One shared administrator password across the fleet. One leaked hash or one compromised BMC then opens every server. Use unique passwords per BMC from a vault.
• Treating ForceUpdate as routine. It can allow downgrades to old, vulnerable firmware. Reserve it for documented exceptions and alert on its use.
• Building OpenBMC with the default signing key. Images signed with the insecure development key pass verification on any board that trusts that key. Supply your own SIGNING_KEY or SIGNING_PUBLIC_KEY.
• Patching the OS and assuming the BMC is covered. OS patch tooling does not deliver BMC updates. Track BMC firmware versions as their own inventory.
• Ignoring disconnected BMCs. A BMC with no cable today keeps its factory credentials until someone plugs it in.
• Treating attestation as vulnerability management. A valid signature proves origin and integrity, not that the firmware is free of known flaws.

FAQ

Is Redfish more secure than IPMI?

The protocol design is. Redfish runs over TLS 1.2 or later, keeps credentials inside the encrypted channel, offers sessions, roles, multi factor authentication and certificate management, and has nothing equivalent to IPMI's RAKP hash disclosure or cipher 0. Real security still depends on the implementation, its patches and your configuration, and on IPMI over LAN being disabled alongside it.

What port does Redfish use?

Redfish uses HTTPS, normally TCP 443 on the BMC's management interface. The port is configurable on many BMCs through the HTTPS object in ManagerNetworkProtocol. IPMI over LAN uses UDP 623 by default.

Can I disable IPMI over LAN with Redfish?

Usually yes, with a PATCH that sets IPMI.ProtocolEnabled to false on the manager's NetworkProtocol resource. Some implementations make the property read only or ignore it, so verify afterwards with a network check from the management segment.

What is the default Redfish service root URL?

/redfish/v1/ on the BMC's address, for example https://bmc01.example.internal/redfish/v1/. The version object at /redfish lists supported major versions. Both are readable without authentication by design.

Should I use Basic auth or sessions for Redfish automation?

Use sessions, or client certificates where supported. Sessions send the password once and then use an X-Auth-Token, can be listed and revoked, and time out on inactivity. Once your tools work with sessions, set HTTPBasicAuth to Disabled.

How do I check BMC firmware versions across many servers?

Read FirmwareVersion on each Manager and the members of UpdateService/FirmwareInventory with a read only account, then compare the results against the vendor's current releases. The inventory script in this guide is a starting point. Run it monthly or quarterly at minimum, which matches the update check cadence NSA and CISA recommend.

What is OpenBMC and who uses it?

OpenBMC is a Linux Foundation project that produces an open source BMC firmware stack built with Yocto, systemd and D-Bus, with bmcweb serving Redfish. It targets servers, top of rack switches and RAID appliances. Organizations use it to build their own BMC firmware or as the base for vendor firmware.

Does a TPM protect the BMC?

Not by itself. The NSA and CISA CSI says TPM attestation is ineffective at mitigating a compromised BMC and that a TPM's presence does not guarantee BMC integrity data is collected. You need hardware designed to measure the BMC firmware itself.

Where Safeguard fits

Redfish and BMC hardening is mostly configuration and firmware work, and Safeguard does not scan firmware images or manage BMCs. The software around them is a different story: the scripts, inventory services, container images and open source libraries your team builds to automate Redfish, and any OpenBMC build tree you maintain, pull in open source dependencies that need the same patch discipline as the rest of your code.

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

The demos below show Safeguard on ordinary software projects, not on BMC firmware. The same flows apply to the code your infrastructure team writes around Redfish: Python inventory tools that depend on DMTF's redfish library, container images that run your BMC audit jobs, and an OpenBMC build repository if you maintain one. Safeguard can scan those with safeguard scan --dir ., --image for a container image, or --sbom for an SBOM file you already have, and it writes results as JSON under ./output. It does not unpack, scan or attest firmware images.

The first demo is a real Safeguard CLI session. After install, safeguard opens the interactive terminal, you ask it to fix the lodash CVE in a repository, 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. It ends with /permissions, /model and /scan. Swap the lodash repository for your Redfish automation repository and the flow is the same: find the vulnerable dependency, propose the change, and run your tests before anything is committed.

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

Management networks are often isolated, which is exactly how BMCs should be run. The local runner demo shows how to set up the runner on your own machine, approve it with its device code, and then scan from the terminal. A runner placed on a jump host or build machine inside the management zone can scan the tooling that lives there without opening that network to the outside.

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

If your team already uses Claude, the third demo shows how to connect Claude to the Safeguard MCP server with OAuth and choose which tools Claude can use. That lets an engineer ask about vulnerabilities in the projects that hold your Redfish scripts and inventory services, using only the tools you have allowed.

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

To try it on your own repositories, download Safeguard and follow the CLI documentation.

Quick check

Sources

• DMTF, Redfish Specification DSP0266 version 1.25.0 (7 August 2026)
• DMTF, Redfish Specification DSP0266 version 1.21.0 (1 August 2024)
• DMTF, Redfish Specification DSP0266 version 1.0.0 (4 August 2015)
• DMTF, Security Protocol and Data Model (SPDM) Specification DSP0274 version 1.4.1 (26 June 2026)
• DMTF, Redfish schema index (DSP8010 schema files)
• DMTF, ServiceRoot schema v1.22.0
• DMTF, AccountService schema v1.19.0
• DMTF, SessionService schema v1.2.0
• DMTF, UpdateService schema v1.17.1
• DMTF, ManagerNetworkProtocol schema v1.14.0
• DMTF, ComponentIntegrity schema v1.5.0
• DMTF, CertificateService schema v1.2.2
• DMTF, Redfish Service Validator README
• DMTF, Redfish Interop Validator README
• NSA and CISA, Cybersecurity Information Sheet: Harden Baseboard Management Controllers (June 2023, archived copy)
• CISA, CISA and NSA Release Joint Guidance on Hardening Baseboard Management Controllers (14 June 2023)
• CISA, Risks of Using the Intelligent Platform Management Interface (26 July 2013, archive)
• NIST NVD, CVE-2013-4786 (IPMI 2.0 RAKP)
• NIST, SP 800-193 Platform Firmware Resiliency Guidelines (May 2018)
• OpenBMC, documentation repository README
• OpenBMC, openbmc repository README (build instructions)
• OpenBMC, Redfish cheat sheet
• OpenBMC, code update architecture
• OpenBMC, bmcweb README
• OpenBMC, phosphor-bmc-code-mgmt build options
• OpenBMC, image_types_phosphor.bbclass (image signing)

Last reviewed: 23 October 2026. Redfish schemas and BMC firmware change often; check the linked DMTF specifications and your vendor's documentation for the properties your hardware supports.