On October 20, CISA, the FBI, the U.S. Secret Service and law enforcement partners in Germany and the United Kingdom released a joint #StopRansomware advisory on SafePay (AA26-293A). The group has impacted at least 600 victims across multiple critical infrastructure sectors since August 2024, and the advisory’s headline mitigations will look familiar: patch edge devices, limit administrator access and require multifactor authentication wherever possible.
That advice is correct, and every operator should follow it. A close read of how SafePay actually operates, however, shows that MFA at the login prompt addresses only the first few minutes of an intrusion. Nearly everything SafePay does after its initial login relies on credentials and trust relationships that MFA was never designed to protect.
How does SafePay get in?
The advisory describes an initial access playbook built almost entirely on credentials and exposed remote access. Operators use exposed or stolen credentials, repeated password guessing, phished accounts and automated exploitation of internet-facing VPN and edge devices. The CVEs named in the advisory map to Cisco ASA and Firepower VPN services, SonicWall SonicOS and Veeam Backup & Replication, flaws that other ransomware groups have been exploiting for years.
SafePay is not relying on novel exploits. It is relying on the fact that a valid username and password, or an unpatched VPN appliance, still opens the door to a large share of the networks that matter most.
What happens after the login?
Once inside, SafePay escalates privileges by creating or elevating accounts, bypassing Windows User Account Control and impersonating security tokens. It moves laterally with PsExec, Windows Remote Management and RDP, all of which accept a valid credential or token without asking whether the session makes sense. The advisory also notes the use of DCSync to pull credentials directly from Active Directory, which effectively hands the operator every account in the domain.
From there the group disables security tools, changes user passwords to lock out legitimate staff, stops the Volume Shadow Copy service and, in some cases, resets network-attached backup storage to factory settings. Only then does it encrypt files and exfiltrate data with common tools such as Rclone, WinSCP and cloud storage clients.
None of these steps triggers a second MFA prompt. MFA protects the human login at the perimeter, while the domain credentials, service accounts, impersonated tokens and machine-to-machine trust that SafePay abuses afterward all sit behind it.
Why does this matter more for operational technology?
The advisory does not break victims down by sector, and nothing in it suggests SafePay deliberately targets control systems. The concern for OT operators is the path the attack takes. At most utilities, manufacturers and pipeline operators, the IT domain that SafePay compromises sits one hop from the control network, connected through jump hosts, historians, engineering workstations and vendor remote access tools.
Inside the control network, the protections that make MFA effective in IT largely do not exist. PLCs, RTUs and HMIs typically cannot prompt for a second factor, most industrial protocols carry no authentication of their own, and devices generally accept commands from anything that can reach them. Certificate-based device authentication was never practical on constrained industrial hardware with long lifecycles and intermittent connectivity, so most OT environments simply went without it.
The result is an environment where an attacker holding a domain administrator credential, or a foothold on a trusted engineering host, inherits the trust of everything downstream. Ransomware that reaches that point does not need to understand the control system to cause an outage, because operators will halt production themselves once they can no longer trust what their systems are telling them, as Colonial Pipeline did in 2021.
What closes the gap?
Patching, MFA, network segmentation and immutable backups remain the foundation, and the advisory is right to lead with them. The structural weakness is the assumption underneath all of them: once a credential is valid, the session that uses it is trusted. Closing that gap means verifying every machine-to-machine session independently, so that a stolen password or harvested domain credential does not translate into the ability to talk to a controller.
This is the gap Autonomous Key Management™ fills in OT environments, where PKI was never viable. AKM establishes authenticated, encrypted relationships between specific devices and refreshes session keys autonomously, without a certificate authority and without sending keys over the wire. A host that is not part of an authorized device relationship cannot produce a verified session with a PLC, there is no standing device credential in Active Directory for DCSync to collect, and a node that is compromised can be cut out of its relationships while the remaining devices refresh. AKM’s sub-1MB footprint and air-gap capability allow it to run on the industrial hardware that certificate infrastructure could never reach.
Encryption inside the control network will not stop SafePay from phishing an employee or exploiting a VPN appliance. What it changes is how far a compromised credential can travel, and that distance is what ultimately decides whether a ransomware incident stays in IT or becomes an operational outage.
What should operators do this week?
- Patch the edge and backup CVEs named in AA26-293A, starting with internet-facing VPN appliances and Veeam servers.
- Enforce MFA on VPN, webmail and any account that can reach critical systems, and audit for accounts created or elevated without a change record.
- Map every path from the IT domain into the control network, including jump hosts, historians and vendor remote access, and treat each one as a trust boundary rather than a pass-through.
- Confirm that backups for both IT and OT systems are offline or immutable, and that restoration has actually been tested.
- Ask which controllers in your environment would accept a command from a compromised engineering workstation today. If the answer is most of them, device-to-device authentication belongs on the roadmap.
About AKMSecure
AKMSecure delivers a patented Autonomous Key Management™ protocol built to replace outdated PKI approaches with a dynamic, quantum-secure, air-gapped-capable architecture. Instead of relying on persistent credentials that can be stolen, reused, or abused, AKM enables independently verified sessions with no standing privileges left behind. The result is a model that better aligns with Zero Trust principles, reduces certificate-based risk, and supports resilient operations across enterprise IT, OT and Tactical Edge environments. Built to NSA-grade security standards and deployable as a lightweight SDK, AKMSecure helps organizations modernize trust at the protocol layer without rebuilding everything around it.
