Server BMC Security: Accounts, Credentials and Firmware for IPMI and Redfish Controllers

A baseboard management controller gives whoever holds its credentials power, console, virtual media and firmware control over a server, below the operating system and its security tools. Network design for the management plane is covered in the Out-of-Band Management Network Design Guide, and the boot chain in the Firmware and Boot Security Guide. This guide covers what those pages only touch: the BMC as an identity system. It explains IPMI and Redfish account models, how to replace shared and factory credentials, directory login and roles, the machine identities that automate BMCs, firmware and configuration baselines, decommissioning, and monitoring. It is for server, infrastructure and data centre teams and the security teams that audit them. Product names (Dell iDRAC, HPE iLO, Lenovo XClarity Controller, Supermicro BMC) are examples, listed alphabetically; confirm settings in each vendor's current documentation.

Key takeaways

• BMC accounts are privileged identities. CISA notes that root on a BMC gives control of hardware, software and firmware, with remote console and BIOS access. Manage BMC accounts like domain administrator accounts.
• Shared fleet passwords are the main weakness. CISA warns that one IPMI password may unlock every machine in a managed group. Every BMC needs a unique local credential held in a vault.
• Prefer Redfish over HTTPS to IPMI over LAN. Redfish uses web standards, sessions and role-based privileges; IPMI over LAN on UDP 623 carries legacy weaknesses such as cipher 0 and anonymous logins that must be turned off.
• Automation identities hold the most power. Provisioning, monitoring and power tools often hold administrator credentials for every BMC; scope, vault and rotate them.
• Decommissioning must clear the BMC. Credentials and directory bindings stay on the controller after a server leaves service unless the BMC is reset or the storage destroyed.

The BMC as an identity system

A BMC is a separate computer on the motherboard with its own operating system, network stack, user database and often directory integration. CISA and NSA's 2023 joint guidance notes that a vulnerable BMC gives attackers a foothold with pre-boot execution potential and keeps running when the server is powered off. NSA summarises the three action areas as credentials and configuration, integrity and updates, and network isolation. The network piece is well covered elsewhere; this guide concentrates on the first two.

Account and credential baseline

The baseline below combines CISA's IPMI guidance with NHI Mgmt Group recommendations.

• Replace factory credentials at receipt: many current servers ship with a unique per-unit default password printed on a label or pull tab; older and some white-box servers ship with a shared default. Either way, change it during build, before the BMC is reachable from the management network, and record the new value only in the vault.
• One unique local account per BMC: keep a single local administrator for break-glass, with a long random password unique to that BMC and stored in the vault with check-out logging. See the Break-Glass Account Guide.
• Directory login for people: bind the BMC to LDAP or Active Directory so administrators sign in as themselves, and leavers lose BMC access when their directory account is disabled. Map directory groups to Redfish roles (Administrator, Operator, ReadOnly) or vendor equivalents.
• Use the BMC's MFA or SSO options where offered: several vendors document two-factor or single sign-on options for the BMC web interface. Where none fits, require MFA on the jump host or privileged access workstation that is the only route to the management network. See the Privileged Access Workstations Guide.
• Disable unused accounts and channels: remove extra local users, disable anonymous and null-user logins, and disable IPMI user access on channels you do not use.
• Protect the directory bind credential: the account the BMC uses to query LDAP is a service account. Give it read-only rights to the groups it needs, use LDAPS, and rotate it. See the Service Account Security Guide.
• Rotate on events: rotate the local break-glass password after each use, after staff with access leave, and fleet-wide after any suspected BMC or vault compromise.

Machine identities that manage BMCs

At scale, people rarely log in to BMCs one by one. Provisioning systems, configuration management, hardware monitoring, power management and bare-metal orchestration tools call Redfish or IPMI with stored credentials. Those credentials are frequently a single administrator account shared across thousands of BMCs.

• Separate accounts per tool: a monitoring tool compromise should not grant firmware rights.
• Keep credentials out of scripts and inventory files: Ansible inventories, Terraform variables and spreadsheets of BMC passwords are common leak points. Retrieve from the vault at run time. See the Secrets Management Guide.
• Own and review: each automation account has a named owner and appears in the service account inventory.

Configuration and firmware baseline

• Services: disable IPMI over LAN unless a tool needs it, Telnet, SSH if unused, SNMPv1 and v2c, unencrypted HTTP, and virtual media and remote console when not in use. Where IPMI must stay, CISA advises restricting UDP 623 to a trusted management VLAN, enabling encryption and disabling cipher 0 and anonymous login.
• TLS: replace self-signed certificates with certificates from an internal CA, and restrict cipher suites to current ones. DMTF publishes a Redfish certificate management white paper (DSP2059) describing how certificates are managed through Redfish.
• Firmware: apply vendor BMC firmware updates with host firmware on a regular cycle, verify vendor signatures where the platform supports it, and record firmware versions in the asset inventory. NIST SP 800-193 frames the goals as protecting firmware from unauthorised change, detecting change and recovering securely.
• Configuration drift: export the BMC configuration through Redfish after build and compare it on a schedule. Several vendors offer a lockdown setting that blocks configuration and firmware changes until it is lifted; use it on stable production servers.
• Host interface: review whether the host operating system can reach the BMC over an in-band interface without credentials, and restrict it where your platform allows, so a compromised host cannot reconfigure its own BMC.

Choosing an approach for your size

Implementing BMC identity controls

1. Discover: scan the management network and, separately, user and server networks for BMC web interfaces and UDP 623. Reconcile against the asset inventory. See the Asset Inventory and CMDB Security Guide.
2. Record accounts: pull local account lists and directory settings from each BMC through Redfish into a register.
3. Pilot: on one rack or cluster, rotate the local administrator to a vaulted unique password, enable directory login, create per-tool automation accounts and update the tools. Run for two weeks and confirm monitoring and provisioning still work.
4. Roll out by fleet segment: automate the change through Redfish from the vault, one segment at a time.
5. Harden services: disable IPMI over LAN and other unused services after automation has moved to Redfish accounts.
6. Rollback: keep the previous credential for each BMC in the vault history for the change window, so a tool or engineer can be restored quickly; local console or the physical reset procedure is the last resort, so test it on one server first.

Decommissioning and returns

CISA notes that documentation on removing IPMI passwords is often unclear, and advises following manufacturer guidance or destroying the flash chip, motherboard or other storage where the password may reside. Before a server is resold, returned under warranty or recycled:

• Remove the BMC from directory groups and revoke its directory bind account.
• Reset the BMC to factory defaults using the vendor's documented procedure, which should clear local users, certificates and network settings.
• Delete vault entries and automation tool records for the BMC.
• Where no reliable reset exists, treat BMC storage as media to sanitise or destroy. See the Data Retention and Secure Deletion Guide.

Detection and measurement

Forward BMC event logs and Redfish audit or session logs to the SIEM through syslog or the management tool. Alert on: local account creation or privilege change, logins with local accounts outside break-glass events, failed login bursts, firmware updates outside change windows, virtual media mounts, configuration changes and BMC web or IPMI ports seen outside the management network. In ATT&CK, use of factory accounts maps to T1078.001 Default Accounts and firmware persistence below the operating system to T1542 Pre-OS Boot.

• Unique credentials: percentage of BMCs with a unique vaulted local administrator password.
• Directory login coverage: percentage of BMCs where people sign in with directory accounts.
• Exposure: BMC interfaces found outside the management network (target: zero).
• Firmware currency: percentage of BMCs on the current approved firmware.
• Automation scope: number of automation accounts with Administrator role across the whole fleet.

Framework mapping

Common failure patterns

• One password for the fleet: every BMC shares the administrator password set at build, so one leaked runbook or compromised tool opens the whole data centre.
• Factory credentials left in place: labels photographed or recorded in tickets, and the password never changed.
• Monitoring tool with Administrator: a health polling tool given full rights because it was simpler, so its compromise grants firmware and virtual media control.
• IPMI left on for one legacy script: UDP 623 stays open fleet-wide because one old tool needs it.
• BMCs reachable from user or server networks: a flat network lets any compromised host reach every controller. See the Network Segmentation Guide.
• Servers returned with credentials intact: warranty swaps and resales leave directory bindings and local accounts on the controller.

Practitioner checklist

• Scan all networks for BMC interfaces and reconcile with the asset inventory.
• Change factory credentials during build, before network exposure.
• Give each BMC a unique vaulted local administrator for break-glass only.
• Enable directory login with group-to-role mapping for people.
• Create separate least-privilege accounts for each automation tool and retrieve them from the vault.
• Disable IPMI over LAN, cipher 0, anonymous login and other unused services.
• Replace self-signed certificates and keep BMC firmware current.
• Forward BMC logs to the SIEM and alert on account, firmware and configuration changes.
• Reset or destroy BMC storage before servers leave your control.

Standards and references

• CISA: Risks of Using the Intelligent Platform Management Interface (IPMI)
• CISA: CISA and NSA release joint guidance on hardening baseboard management controllers
• NSA: NSA and CISA release guide to protect baseboard management controllers
• DMTF: Redfish Specification DSP0266
• DMTF: Redfish standards and related documents
• NIST: SP 800-193 Platform Firmware Resiliency Guidelines
• NIST: SP 800-53 Rev 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Out-of-Band Management Network Design Guide · Firmware and Boot Security Guide · Firmware and Bootkit Compromise Playbook · Hardware Root of Trust Guide