APT29 first reached SolarWinds by spraying passwords against administrative accounts that had no device-bound proof requirement. Once the attackers controlled the build system they inserted the SUNBURST implant into signed Orion updates. After customers installed those updates, the same group located SAML signing keys inside federated environments and issued forged assertions that granted access to downstream services without any interactive login.

How Password Spraying Created the Initial Foothold

The attack began with ordinary credential guessing against SolarWinds infrastructure. Because authentication relied on passwords alone, any account that accepted a sprayed value gave the attackers a persistent position inside the software supply chain. From there they reached the Orion build pipeline and tampered with updates that carried legitimate SolarWinds signatures.

Even if a time-based OTP or push had been in place, it would not have stopped this attack. Password spraying succeeds before any second factor is challenged; the attacker simply needs one account that accepts the sprayed password. Second factors can also be intercepted or phished because they are not device-bound. A device-bound, phish-proof credential eliminates this class: the private key never leaves enrolled hardware and signatures are origin-bound — nothing to intercept, proxy, or replay.

Why Stolen Federation Keys Removed Any Authentication Barrier

After SUNBURST executed, APT29 searched for Active Directory Federation Services or equivalent identity providers. In affected customer networks the group extracted the private keys used to sign SAML assertions. With those keys the attackers could mint valid tokens for any user or service.

The theft occurred after administrative access had already been obtained, so the SAML signing material lived in memory or on disk outside any login control. Server-side extraction of federation keys sits outside what login factors can block. Nevertheless, device-bound credentials would have altered the earlier stages by eliminating the password-spraying entry at SolarWinds and raising the bar for the administrative access needed to reach signing material inside customer environments.

How Device-Bound Signatures Close Both Phases

Device-bound credentials remove the password-spraying surface that gave APT29 its first foothold at the vendor. Every authentication or device enrollment now requires a hardware-backed signature whose private key never leaves the enrolled device, so spraying campaigns produce no usable session. The same property challenges later movement: reaching a SAML signing certificate still requires administrative rights, yet those rights can no longer be obtained through reusable credentials that have already been eliminated.

MFA 2.0 does not prevent server-side theft of a signing key once an attacker already holds administrative code execution. It does ensure that the path to that administrative position must itself rely on physical possession of an enrolled device rather than a phishable factor. The technique class here is Golden SAML: forged assertions signed with a stolen private key that services accept without re-authentication. Device-bound keys make the assertions themselves non-reusable across requests because each signature must be freshly generated by hardware the attacker does not control. Full lifecycle coverage further requires the same device-bound proof during registration and device onboarding, closing the enrollment paths that passkeys alone leave exposed.

FAQ

Could stronger passwords at SolarWinds have stopped the whole chain?

Stronger passwords would have made the initial spraying campaign harder, yet they would not have prevented later extraction of SAML signing keys once attackers already held administrative access inside victim networks.

Did SUNBURST itself exfiltrate the high-value data?

Most sensitive access occurred after forged SAML assertions were accepted. The implant primarily delivered persistence and reconnaissance; the stolen federation keys performed the actual authorization abuse.

Why did MFA prompts never appear during the SAML abuse phase?

Forged assertions bypass the login flow. Services accepted the signed token as evidence that authentication had already occurred, so no interactive factor was ever challenged.

Would device-bound credentials have changed SolarWinds customer outcomes?

They would have stopped the password-spraying entry at the vendor and made it substantially harder for the same actors to obtain the administrative rights needed to locate and steal SAML keys inside downstream environments. ---END REVISED POST---