When the Traffic Cop Kept Its Keys in the Backup: The OTTO Fleet Manager Advisory (ICSA-26-239-03) Through an ANSI/A3 R15.08 and IEC 62443-4-2 Lens

This is a 6.8. It is not remotely exploitable, there is no known exploit, and the fix shipped with the advisory. On the CISA severity ladder it barely registers, and if you triage by score you will close this ticket in a week and never think about it again. I want to argue for thinking about it slightly longer, because of what the affected product is. OTTO Fleet Manager is the software that tells a fleet of autonomous mobile robots where to go, how fast, and which parts of the floor they are allowed to be in. The vulnerability is boring. The artifact it lives in is not.

On August 27, 2026, CISA published seven ICS advisories. Six of them are the usual mix — Mitsubishi FA product updates, a couple of Chinese IoT gateways, a fuel-management controller, a comms test set used in water and energy. The seventh, ICSA-26-239-03, covers Rockwell Automation OTTO Fleet Manager, and it is the only one in the batch whose product supervises machines that move around a floor with people on it.

The public record

CVE-2026-75112. Affected versions are OTTO Fleet Manager up to and including V2.36.2. The weakness is CWE-916, use of a password hash with insufficient computational effort: the product's bcrypt implementation uses a work factor low enough to meaningfully reduce the cost of an offline brute-force attack against stored password hashes. CVSS v3.1 base score 6.8; CVSS v4.0 base score 6.9. CISA reports no known public exploitation and states the vulnerability is not exploitable remotely.

The exploitation path CISA describes is one sentence long and is the whole story: if an attacker gains access to an unencrypted system backup, the weakly hashed credentials could be more easily compromised. That is the delivery mechanism. Not a network service, not an authentication bypass, not a parser. A backup file.

Rockwell fixed it in software version 2.36.3 and published Rockwell security advisory SD1791, which — per the trade coverage — also carries instructions for enabling encrypted system backup in OTTO Fleet Manager. Read that ordering carefully. The patch changes the work factor. The advisory tells you to turn on a feature that was evidently not on by default. Those are two different remediations, and only one of them is a code change.

Sector listing on the advisory: critical manufacturing and transportation systems, deployed globally.

Now the part the advisory does not say, because advisories do not say it. OTTO by Rockwell Automation builds the OTTO 100, 600, 1200, 1500 and Lifter AMRs. The company states its fleet complies with ISO 3691-4, ANSI/RIA R15.08-1 and ANSI/ITSDF B56.5; that key safety-related parts meet performance level d under ISO 13849-1; that the machines carry CE marking; that they are audited twice a year by Pilz Automation Safety Canada; and that OTTO was a co-author of R15.08-1 itself. That is a real safety case, built by people who know how to build one, and nothing in this advisory dents it.

That is precisely why the advisory is interesting. The vulnerability is not in the safety case. It is next to it.

The standards lens

An AMR deployment is governed by a split. Understanding where the split falls is the entire analysis.

On the vehicle — the safety-rated half. ANSI/A3 R15.08-1-2020 (122 pages, manufacturer-facing) specifies the design requirements for the industrial mobile robot itself: modes of operation, protective stop and emergency stop functions, stopping distance as a function of speed and rated load and surface, collision avoidance, velocity limiting, presence-sensing devices, and safety-related parts of control systems with their performance requirements. Annex C is normative and sets the parameters and thresholds for determining required safety function performance. This is where safety-rated LiDAR, fieldset switching, speed monitoring and brake actuation live. This is the PL d part. ISO 3691-4:2023 covers the same ground for driverless industrial trucks, and its 2023 revision tightened the definitions of the active detection field and the operational stop specifically.

Above the vehicle — the not-safety-rated half. R15.08-1 §5 also contains a clause on IMRs intended to operate as part of a fleet, and it says something structurally important: the IMR shall communicate the information the fleet manager needs in order to determine whether the IMR is compliant with the fleet management, and where it is not compliant, the IMR shall remain inactivated. R15.08-2-2023 covers integration and the facility-specific adaptation. R15.08-3-2026 — published this year — covers user responsibilities for day-to-day safe operation of IMRs and IMR fleets.

So the standards suite explicitly contemplates a fleet manager, explicitly gives it an arbitration role, and explicitly hands the user a set of ongoing operational duties. What no part of the suite does is assign the fleet manager a performance level. It is not a safety controller and nobody claims it is. The AMR is designed so that it protects the person in front of it whatever the fleet manager says.

Here is the gap. "The AMR will not run someone over regardless of its mission" is a true and well-verified claim about the protective stop. It is not a claim about everything the fleet manager decides. Consider what actually lives in a fleet manager's configuration state:

| Configuration item | Held by | Safety-rated? | What it constrains | | --- | --- | --- | --- | | Protective stop on field intrusion | AMR on-board safety controller | Yes — PL d | Contact with a person | | Safety-rated speed monitoring | AMR on-board safety controller | Yes — PL d | Overspeed | | Field set selection logic | AMR on-board safety controller | Yes — PL d | Detection zone vs. current speed | | Site map and zone geometry | Fleet manager | No | Where robots may travel | | Restricted-zone designation | Fleet manager | No | Where elevated speed is permitted | | Commanded travel speed per segment | Fleet manager | No | Nominal speed request | | Mission assignment and traffic rules | Fleet manager | No | Density, deadlock, queueing | | Fleet compliance arbitration | Fleet manager | No | Whether a non-compliant IMR stays inactivated | | User accounts and roles | Fleet manager | No | Who can change any of the above |

Every row in the bottom half is an assumption the top half was validated against. ISO 3691-4:2023 permits operation at higher speed in restricted zones — but only where a detailed hazard analysis has been done and corresponding additional measures implemented. The restricted-zone designation is therefore not a convenience setting. It is the visible end of a risk assessment. And it is stored as data, in a database, under an account, in a product whose password hashes were until recently cheaper to crack than they should have been, in backups that were not encrypted unless someone went and turned that on.

IEC 62443 is the frame for the bottom half. OTTO Fleet Manager is a software application in an IACS, so IEC 62443-4-2's software application requirements apply on top of the common component requirements:

CR 1.5 (Authenticator management) requires authenticators be protected from unauthorized disclosure and modification, in storage and in transit. A hash is a storage protection; its work factor is the strength of that protection. CWE-916 is a CR 1.5 finding by definition.
CR 4.1 (Information confidentiality) covers information at rest for which unauthorized disclosure is a concern. A full system backup is information at rest. Shipping it unencrypted by default is the actual exposure; the weak hash only sets the price once someone has it.
CR 3.4 (Software and information integrity) is the one nobody invokes here and should. If an attacker recovers administrative credentials from a stale backup, the exposure is not confidentiality. It is write access to the site map.
IEC 62443-4-1 SD-4 (secure design best practices) and SVV-3 would have caught a low bcrypt cost as a design-review item rather than a CVE, because cryptographic parameter selection is the textbook example of a thing you fix once in a design standard instead of five times in advisories.

ISO 10218-2:2025 closes the loop. The 2025 revision of the industrial robot integration standard now requires a cybersecurity risk assessment as part of the integration risk assessment, on the reasoning that a security compromise which alters a safety-relevant parameter is a safety matter. AMRs sit under R15.08 rather than ISO 10218, but the reasoning transfers intact, and R15.08-3-2026's user obligations are exactly where that assessment should land for a fleet.

A worked snippet: the risk row nobody wrote

Here is the row I would expect to find in a fleet integrator's combined safety-and-security assessment, and which the CVSS score does not represent because CVSS scores components, not deployments.

Damage scenario DS-01 — unauthorized modification of site zone configuration.

| Field | Value | | --- | --- | | Asset | Fleet manager site map and zone configuration (restricted-zone designations, segment speed limits, keep-out polygons) | | Threat scenario | Attacker obtains an unencrypted OTTO Fleet Manager system backup from a file share, engineering laptop or decommissioned host; cracks administrator hash offline; authenticates to the live fleet manager; re-designates a mixed-traffic aisle as a restricted zone | | Attack path | CVE-2026-75112 (CWE-916) reduces offline cracking cost. Backup encryption disabled by default supplies the ciphertext-free artifact | | Safety consequence | Elevated commanded speed in an aisle whose ISO 3691-4:2023 restricted-zone justification does not exist. On-board protective stop still functions; stopping distance at the higher speed was never validated for that aisle's escape clearance | | Residual barrier | AMR on-board PL d protective stop and safety-rated speed limit (vehicle maximum, not aisle maximum) | | Impact rating | Severe — foreseeable serious injury via reduced escape clearance, not via loss of protective stop | | Attack feasibility | Low to Medium — requires local/adjacent access to a backup artifact plus offline compute | | Risk | Medium, and entirely dependent on a control (backup encryption) that ships off |

Note what the residual barrier does and does not do. The protective stop still stops the machine. What has changed is the geometry: at higher speed the stopping distance grows, and R15.08-1's stopping-distance requirement is stated as a function of speed, maximum rated load and specified operating environment. The person's escape clearance was sized for the validated speed. Nobody re-ran that calculation because nobody was told the number changed.

The fault tree for the top event is short, which is usually a bad sign:

TOP: Person struck / insufficient escape clearance in mixed-traffic aisle
                          |
                        [AND]
          ______________/    \______________
         |                                  |
  Commanded speed exceeds            Escape clearance sized
  aisle validation basis             for validated speed only
         |                                  |
       [OR]                          (site layout — static,
   ____/  |  \____                    no runtime check)
  |       |       |
Zone    Segment  Map
config  speed    version
altered altered  rolled back
  |       |       |
[OR]------+-------+
  |
Unauthorized fleet-manager write access
  |
[OR]
  |-- Credential recovered from unencrypted backup  [CVE-2026-75112]
  |-- Shared/again-used admin account
  |-- Departed-employee account not revoked

Every leaf under that bottom OR gate is an IEC 62443-2-1 account-management finding, and none of them are in the CVE. The CVE is one leaf. The gate is the problem.

Derived requirements (excerpt)

Written the way I would hand them to a fleet integrator, with numbers in them, because a requirement without a threshold is a wish.

FM-SEC-001 (IEC 62443-4-2 CR 4.1). All OTTO Fleet Manager system backups shall be encrypted at rest using an approved algorithm with a key that is not derivable from the backup itself. Backup encryption shall be enabled by configuration audit within 30 days of this requirement's baseline, and its enabled state shall be re-verified at every scheduled maintenance window, at intervals not exceeding 90 days. Evidence: configuration export showing encryption enabled, dated and signed.

FM-SEC-002 (IEC 62443-4-2 CR 1.5). OTTO Fleet Manager shall run at V2.36.3 or later on all instances. All local account passwords shall be rotated after the upgrade, because upgrading the work factor does not re-hash credentials that were stored under the old one. Rotation shall complete within 14 days of upgrade. Any backup taken before the rotation completes shall be treated as containing live credential material and destroyed or re-encrypted accordingly.

FM-SEC-003 (R15.08-2 §integration / R15.08-3 §user duties). Site zone configuration — restricted-zone designations, per-segment speed limits and keep-out polygons — shall be designated a controlled safety-relevant configuration item. Every change shall carry a reference to the ISO 3691-4:2023 restricted-zone hazard analysis that authorizes it. Changes without such a reference shall be rejected by process, and detected by a configuration-diff review performed no less than monthly.

FM-SEC-004 (ISO 3691-4:2023 restricted zones / R15.08-1 Annex C). For each aisle or segment where commanded speed exceeds the general-area speed, the stopping distance at that speed, at maximum rated load, on the specified travel surface, shall be documented alongside the available escape clearance, with a stated margin. Where margin is not demonstrated, the segment shall not be designated restricted. This document shall be re-verified whenever the map version or the segment speed changes.

FM-SEC-005 (IEC 62443-2-1 / R15.08-3-2026). Fleet manager accounts shall be individually attributable — no shared administrator credential — with role separation between mission operation and map or zone editing. Account inventory shall be reconciled against HR separation records at intervals not exceeding 30 days. Zone-editing privilege shall be held by no more than the number of named individuals recorded in the site safety file.

None of those five require Rockwell to ship anything. Four of them are things a user organization does, which is exactly the audience R15.08-3-2026 was written for.

What the headline really tells us

The headline is "medium-severity credential-hashing flaw in a warehouse robot fleet tool, patched." That is accurate. Patch it.

The engineering finding is a boundary problem, and it is the same boundary problem I keep writing about in different industries. A safety case is a set of claims plus the assumptions those claims rest on. Engineering effort concentrates almost entirely on the claims, because the claims are the part with test reports and third-party audits attached. The assumptions get written into configuration, and configuration gets treated as operations rather than as engineering.

The OTTO safety case is strong where it was designed to be strong. PL d safety-related parts, safety-rated LiDAR, fieldset switching, twice-yearly third-party audit, co-authorship of the standard. Everything the vehicle does to keep from hitting a person is verified. But the sentence "this AMR travels at X in this aisle, where the escape clearance is Y" is half validated engineering and half a row in a database, and the database is the part that had a low bcrypt cost and unencrypted backups.

A backup is not an operations artifact. A backup is a complete, portable, offline copy of every safety-relevant assumption your site has recorded, in a file that by design gets copied to places your security zone diagram has never heard of — a share, a laptop, a vendor's support ticket, a host you decommissioned in 2024 and left on a shelf. Draw your security boundary around the running system and the backup will walk straight through it carrying the map.

The other thing worth keeping is the sequencing in the vendor's own remediation. The CVE is closed by a version number. The exposure is closed by a checkbox that was off. Somebody had to write, in an advisory, instructions for enabling encrypted system backup — which means the option existed, was documented, and was not the default. Defaults are requirements. A control that ships off is a control the risk assessment does not get to count, and if your assessment counted it anyway, the assessment is wrong today and was wrong the day you wrote it.

Upgrade to 2.36.3. Rotate the passwords afterward, not before. Then go find every copy of your fleet manager backup and ask which of them is currently a plaintext record of where your robots are allowed to drive fast.