Every way in to the power.
See every component that controls power in your fleet, the firmware it runs, the settings and secrets that reach it, and the gap between what it reports and what the rail actually does.
Request a pilot| Layer | Asset | Model | Firmware | Source |
|---|---|---|---|---|
| BMC | gpu-node-17 | Dell iDRAC9 | 7.10.50 | Redfish |
| Regulator | CPU0 VCORE | Infineon XDPE | rev 2A | Redfish * |
| GPU board | HGX · 8× H100 | NVIDIA HGX | 24.03 | HMC |
| PSU | PSU 1 | Delta 3,200 W | 00.0E.02 | Redfish |
| Rack power | R12 · PDU A | Raritan PX4 | 4.2.0 | SNMP |
Map every power component, from day one.
PWX connects to the management interfaces you already run and lists every component that controls power: BMCs, voltage regulators, power supplies, GPU baseboards and rack PDUs.
- Read-only through Redfish, IPMI, DCGM and SNMP
- Model, firmware and the source of every record
- Nothing installed on the servers
Track the firmware on the power path.
Firmware for BMCs, regulator controllers, power supplies and GPU baseboards, split by version across the fleet. Versions behind the current release and versions with known CVEs stand out, so the fixes that close a path to the power go first.
- BMC, VRM controller, PSU and HMC firmware in one view
- Drift caught when a device falls back or diverges
- Known CVEs matched to the exact version
See what an attacker can reach.
Look at the fleet the way an attacker does, from the outside in: management interfaces open to the internet, IPMI that accepts a login without a password, Redfish reachable from tenant networks, PDUs with default write access. Every one of them is a road to a rail.
- BMC, IPMI, Redfish and PDU exposure across every vendor
- Severity and the number of assets behind each finding
- Read-only checks; no password guessing, ever
Catch drift on the settings that reach the power.
A short list of settings decides whether an attacker on a host can reach a rail: BMC accounts, the host-to-BMC channel, firmware age and regulator write-protection. PWX re-checks them every four hours across every vendor.
- Baselines per vendor, one score per setting
- Write-protection confirmed by the agent, not assumed
- Findings ranked by the hardware they expose
- 47 BMCs
rootsame local password on every BMC1,128 rails · 376 GPUs - 64 BMCs
ipmi-adminunchanged for 3 years1,536 rails · 512 GPUs - 128 hosts
Host Interfacehost can reach its BMC without the network128 servers - 24 PDUs
privatedefault SNMP write community12 racks
One secret, measured in hardware.
Shared and unchanged credentials are the usual way in to a BMC. PWX does not stop at counting machines: it follows each secret to the rails and GPUs it could power down, so the riskiest password gets rotated first.
- Shared, default and never-rotated BMC accounts
- Host Interface and SNMP write communities
- Blast radius in rails, GPUs and racks
2 new · 1 confirmed fixed
1 new
nothing new
Fix what protects the most hardware.
A thousand findings do not need a thousand tickets. PWX ranks each fix by the GPUs and rails it puts out of reach, and re-scans after every change to confirm it held. A critical CVE with no path to the power can wait; an open path to 3,600 GPUs cannot.
- Ranked by protected hardware, not by alert count
- Every fix re-verified on the next scan
- New exposure caught as soon as it appears
What the device says, against what the rail does.
Inventory tells you what a component reports about itself. PWX also measures what the rail physically does. When the controller reports one voltage and the rail runs at another, that gap is the signature of firmware that lies, and it raises a verdict on its own.
- Commanded vs measured, checked continuously (L3)
- Runs on our bench today; on servers it reads the BMC command log in the pilot
- Physical evidence, not a configuration opinion