Redfish vs IPMI: Differences Security and Migration Considerations

Redfish and IPMI both let administrators manage hardware through a baseboard management controller (BMC), including when the host operating system is unavailable. They solve that out-of-band management problem through different interfaces. IPMI defines command-oriented messages and transports that have been deployed for decades; Redfish defines a resource-oriented web API built around HTTP, JSON and a published data model. The difference affects client software, security controls, interoperability and how teams evolve a product. For a new platform, Redfish is generally the stronger interface for automation and fleet management. IPMI remains relevant where existing tools, local interfaces or installed equipment depend on it. Migration therefore means mapping operational tasks and validating behavior, not simply changing a protocol setting.

What Redfish and IPMI Manage

A BMC is an independent controller that monitors and controls platform hardware. It can report temperatures, voltages, fan status and inventory; record events; and perform actions such as power cycling or resetting a host. It can remain available while the main processor is off or its operating system has failed. Both IPMI and Redfish expose management functions through the BMC, but neither replaces the BMC firmware, board-level sensors or the underlying hardware controls.

IPMI (Intelligent Platform Management Interface) specifies management architecture, commands, event formats, records and interfaces. Clients send defined command messages to request sensor readings, retrieve the system event log, change power state or access inventory. Common access paths include the local system interface and IPMI over LAN. IPMI 2.0 RMCP+ commonly uses UDP port 623 for remote management.

Redfish is a DMTF standard for remote, out-of-band management. A client discovers resources from a service root, then uses HTTP methods such as GET, PATCH and POST against URIs. Responses use JSON representations described by Redfish schemas. Resources represent systems, managers, chassis, sensors, logs, network interfaces, firmware inventory and other platform components. Redfish supports synchronous and asynchronous operations and event subscriptions, depending on the service implementation.

Redfish vs IPMI at a Glance

A standards label does not guarantee identical feature coverage across vendors. Check the BMC’s supported commands, Redfish version, schemas, privileges and OEM extensions before designing a client.

Key Differences for Embedded and Platform Teams

Command Set Versus Discoverable resources

IPMI clients usually need to know which command to send and how to interpret its response. The approach is compact and works well for direct operations such as reading a sensor or switching power. However, fleet tools can accumulate command tables, vendor-specific extensions and translation logic. That work becomes harder when platforms expose different sensors or optional capabilities.

Redfish represents the platform as linked resources. A client can follow the service’s links, inspect properties and use schema-defined operations. This helps management software scale across products and makes payloads easier to inspect during development. The trade-off is that teams must implement an HTTP service, JSON processing, resource modeling, authentication, TLS and update handling within the BMC’s compute and memory limits. Redfish is a management API, not a guarantee that every device implements every resource.

Security Differences and Operational Controls

Redfish uses HTTPS and modern web security mechanisms, including TLS, sessions or other supported authentication methods, role-based privileges and certificate management. Current DMTF specifications define protocol behavior and security requirements, but product security still depends on the implementation: certificate validation, credential storage, authorization checks, secure update paths and timely patching all need engineering and operational controls. A reachable Redfish endpoint is still a powerful management surface.

IPMI’s security posture varies by version, cipher suite, BMC firmware and deployment. IPMI 2.0 can use authenticated and encrypted RMCP+ sessions, but legacy configurations may permit weak settings, shared credentials or broad network reachability. Treat IPMI-over-LAN as a privileged interface: disable it if unused, restrict it to a dedicated management network, remove default accounts and verify supported cipher suites. These precautions also apply to Redfish; HTTPS does not make an exposed management network safe by itself.

The IPMI promoters’ 2020 statement said no new specification updates were planned and encouraged consideration of modern management interfaces such as Redfish. It also clarifies that this applies to the specification, not existing implementations. That is a lifecycle signal, not a reason to abruptly remove a functioning interface from deployed products.

Where Each Interface Fits

For data-center servers, storage and network equipment, Redfish is useful when operators need a consistent, discoverable API for provisioning, health monitoring, firmware inventory and fleet automation. Its JSON and HTTP model also suits integration with orchestration services and test frameworks. IPMI can remain necessary for existing data-center workflows, legacy hardware and recovery tools that rely on commands outside a product’s Redfish coverage.

In industrial controllers, edge appliances and other embedded products, the choice depends on the management plane’s role. A device may need only a small, local management interface, which can favor an existing IPMI implementation or a narrower custom interface. A product intended for remote fleet operation may benefit from Redfish’s resource model and eventing. In either case, the BMC must be included in the threat model, update strategy and production test plan.

Teams building or modifying management firmware can connect this work to OpenBMC development and integration. The OpenBMC vs Yocto article explains how the firmware platform relates to the build system. For board-specific Linux and boot integration, see BSP development.

Planning an IPMI to Redfish <igration

Migration is an application and product change. Redfish is not a wire-compatible replacement for IPMI commands, and an existing client cannot generally switch transports and continue unchanged. Start with operations and required outcomes, then map each one to standard Redfish resources or actions. For example, “read inlet temperature,” “retrieve recent hardware faults,” “set one-time boot target” and “power-cycle host” are distinct workflows with different resource paths, privileges and response behavior.

• Inventory current clients, scripts, IPMI commands, vendor extensions, polling intervals, alerts, credentials and recovery procedures.
• Map each required operation to Redfish schemas, actions and events. Record gaps, OEM-only behavior and any functions that must remain on IPMI or a local interface.
• Check the target BMC firmware’s Redfish version and actual resource coverage. Exercise discovery, pagination, asynchronous tasks, error responses and privilege boundaries.
• Build an adapter or dual-stack period when operators need continuity. Keep one source of truth for actions and audit logs; define how conflicts are prevented if both interfaces can change state.
• Test security and failure behavior: certificate rotation, expired credentials, network loss, BMC reset, interrupted updates, rate limits, authorization failures and event delivery recovery.
• Roll out by hardware model or site. Compare telemetry and command outcomes, document rollback, update runbooks, then disable legacy access only when dependent clients and recovery paths have been verified.

A migration may also require firmware changes, resource-model design, certificate provisioning and automated conformance testing. Conclusive Engineering’s Firmware and Software Services include OpenBMC firmware, Redfish interface development, security hardening and standards compliance. Use the appropriate BMC and product scope when defining the work.

Common Migration Mistakes

• Assuming all Redfish implementations expose the same optional resources or OEM actions.
• Translating commands one-for-one without defining the operational outcome or error handling.
• Leaving IPMI enabled indefinitely without isolating, monitoring or documenting it.
• Testing only successful requests and omitting access denial, partial failure and recovery behavior.
• Using self-signed certificates without a lifecycle plan for trust, renewal and rotation.
• Validating a Redfish service only against schema while ignoring real client interoperability and performance.

Frequently Asked Questions

Is Redfish replacing IPMI?

Redfish is the modern DMTF management interface that IPMI promoters point to as an alternative. The IPMI specification is not planned for further updates, but deployed IPMI implementations continue to exist. Product migration depends on client, platform and support requirements.

Is Redfish more secure than IPMI?

Redfish is designed around HTTPS and current web security mechanisms, which provide a stronger baseline for remote API use. The actual result depends on correct TLS, authentication, authorization, firmware updates and network isolation. IPMI can also use authenticated and encrypted sessions, but legacy configurations need careful review.

Can Redfish and IPMI run at the same time?

Many BMCs expose both, but support is vendor- and firmware-dependent. If both interfaces can change platform state, define shared authorization, audit and concurrency behavior, then restrict each endpoint to the clients and networks that need it.

Does Redfish require OpenBMC?

No. Redfish is an API standard and can be implemented in different BMC firmware stacks. OpenBMC is one open-source firmware platform that includes Redfish support and enables product-specific customization.

What should teams test before switching clients?

Test the real workflows, privileges, resource coverage, asynchronous operations, events, error handling, TLS and recovery paths on every target BMC model. Validate both interoperability and the operational runbooks used during outages.

Conclusion

IPMI remains a practical interface for established platforms, local management paths and tooling that depends on its command set. Redfish offers a discoverable, schema-based API that fits modern automation and ongoing platform evolution. Choose based on actual client requirements, BMC resources and support lifetime. When migrating, map workflows, secure both management surfaces, test vendor coverage and roll out with a verified recovery path. The work often crosses BMC firmware, board support and security engineering; plan those dependencies alongside the API change.