MFA 2.0 stops Colonial legacy VPN password login

Q: Would MFA 2.0 have blocked DarkSide's Colonial VPN login?

Yes. According to [Mandiant's Charles Carmakal in House testimony](https://www.congress.gov/117/meeting/house/112689/witnesses/HHRG-117-HM00-Wstate-CarmakalC-20210609.pdf), the earliest evidence of compromise was a 29 April 2021 login to a Colonial VPN on a legacy profile using an employee username and password without a one-time passcode. CEO Joseph Blount told the Senate that legacy VPN used only single-factor authentication. Phishing-proof MFA 2.0 removes transferable passwords from workforce remote access, so password alone cannot complete the tunnel. The inactive account left enabled would still have needed a device-bound proof the attacker did not hold.

DarkSide reached Colonial Pipeline through a legacy VPN that took an employee password and nothing else. Phishing-proof MFA 2.0 would have stopped that password-only sign-in cold. It would not have rolled back ransomware once the tunnel was already open.

DarkSide's Colonial Pipeline intrusion began on a legacy workforce VPN that accepted an employee username and password with no one-time passcode. Phishing-proof MFA 2.0 closes that password-only gate so a stolen or reused credential alone cannot open the tunnel. It does not undo ransomware or the reported ~100 GB exfiltration after a live VPN session already exists. For the full attack-chain narrative, read the companion on legacymfa.sucks.

FAQ

Would MFA 2.0 have blocked DarkSide's Colonial VPN login?

Yes. According to Mandiant's Charles Carmakal in House testimony, the earliest evidence of compromise was a 29 April 2021 login to a Colonial VPN on a legacy profile using an employee username and password without a one-time passcode. CEO Joseph Blount told the Senate that legacy VPN used only single-factor authentication. Phishing-proof MFA 2.0 removes transferable passwords from workforce remote access, so password alone cannot complete the tunnel. The inactive account left enabled would still have needed a device-bound proof the attacker did not hold.

What does MFA 2.0 change on a Colonial-style password-only VPN?

It replaces the single shared secret with device-bound, origin-bound signatures. There is no password database worth stealing for that login path, and no OTP, SMS code, or push approval to intercept or coach. A prevention-first architecture stops the remote sign-in instead of waiting to detect ransomware after the foothold. Defenders still disable dormant VPN profiles and unused accounts; phishing-proof controls do not excuse leaving dead identities reachable.

Does MFA 2.0 stop ransomware after a Colonial-style VPN foothold?

No. Once DarkSide held an established Colonial VPN session, ransomware disruption beginning 7 May 2021 and the reported ~100 GB exfiltration were post-authentication work on the corporate network. No login MFA design revokes a session that already exists or freezes encryption already underway. Closing the password-only VPN login stops that entry path. Malware and operator action after a live tunnel are a harder, separate containment problem.

Is adding OTP to VPN the same as MFA 2.0 for this breach?

No. OTP on VPN would have raised the bar above Colonial's documented single-factor failure, but OTP remains a transferable factor. MFA 2.0 is phishing-proof across the identity lifecycle: the private key never leaves the enrolled device, and there is no reusable secret to type or relay. Passkeys are phishing-resistant at the login act; phishing-proof MFA 2.0 is stronger on the ladder because it keeps phishable factors out of registration, device onboarding, and authentication alike. For Colonial, public reporting does not establish how the password was obtained, so the durable fix is removing password-only remote access entirely, not stacking another code channel on the same legacy profile.

What should CISOs lock down first after a Colonial-style VPN lesson?

Every workforce VPN and remote access path must refuse password-only sign-in, including inactive accounts still enabled on legacy profiles. Require phishing-proof device-bound authentication so a reused employee password cannot mint a corporate tunnel by itself. Teams that dropped legacy MFA treat single-factor remote access as an open door, not a temporary exception. Public reporting does not establish the Colonial password source; fix the gate rather than betting on detection after the attacker is inside.