The US Fire Administration's report "Firefighter Fatalities in the United States in 2024," published in June 2025, counts 72 on-duty firefighter deaths. It calls that the second lowest annual count since tracking began. Honest reading of the data matters here, because it limits what robots can claim.
What the numbers say
From the USFA executive summary:
- Stress and overexertion were the leading cause of fatal injury at 58 percent.
- Being struck by objects was second at 13 percent, and vehicle collisions third at 11 percent.
- Cardiovascular events were 58 percent of deaths by nature of injury, and trauma 21 percent.
- 68 percent of deaths happened while operating at an incident. Fireground operations were the most common duty at 36 percent.
- Six deaths involved brush, grass or wildfire firefighting, the lowest in ten years.
A robot that enters a burning building or a collapsed structure addresses the trauma and fireground slice. It does not address overexertion or cardiovascular events, which make up most of the count. Anyone selling a rescue robot as a fix for firefighter deaths should be asked which causes it touches.
Where robots and remote tools help
- Reconnaissance into smoke filled or unstable spaces, so crews see before they enter.
- Remote hose and monitor handling for fires too hot or too unstable to approach.
- Search in rubble with cameras and sensors where a person cannot yet go.
- Drones for overhead views of a large fire or a wide search area.
What the software must get right
- Safe stop and loss of link behavior. Radio links fail inside buildings and rubble. A machine must stop, hold or return in a known way.
- Human decision on any action near people. The robot may carry sensors that suggest a victim is present. A person decides what happens next.
- Secure updates. Many such robots run open robotics software and third party libraries. Updates should be signed and tracked against an inventory.
- Tamper evident logs. After a mission, crews and investigators need a record of commands, video and sensor data that cannot be altered unnoticed.
- Offline operation. The robot cannot rely on a cloud service at an incident scene.
- A bill of materials. When a vulnerability is published in a robotics library, the maker and the buyer should be able to say within an hour whether the fleet contains it.
What to do now
- Ask the maker for an SBOM in CycloneDX or SPDX for the robot software and firmware.
- Check it against the CISA Known Exploited Vulnerabilities catalog.
- Test link loss in a training exercise, not only in a lab.
- Ask how updates are signed and who holds the keys.
How Safeguard fits, and where it stops
Safeguard does not build or operate robots and this post does not claim it saves lives or reduces injuries. It generates and imports SBOMs, scans firmware, containers and dependencies with known exploited status and reachability, applies policy gates, keeps audit logs, and can run on premises or air gapped with offline models.
Try it yourself
List the software components of one device you rely on, even a simple one. The demo below generates an SBOM so you can see what such a list looks like.
Click through it at your own pace, or open it full screen.
Quick check
Which causes in the USFA data are least affected by a rescue robot?
Stress and overexertion (58 percent) and cardiovascular events (58 percent by nature of injury), which are not caused by entering a hazardous space.
Why does offline operation matter at an incident?
Cloud services may be unreachable inside buildings or in remote terrain, and the machine still has to behave safely.
