The SolarWinds Breach: What Most Retrospectives Got Right, and What They Quietly Missed
- Martin Snyder

- May 13
- 3 min read
The SolarWinds compromise — disclosed in December 2020 — became the defining supply-chain incident of the early 2020s. The widely-known narrative is straightforward: a sophisticated actor compromised the build environment of the SolarWinds Orion product, inserted malicious code into a software update, and used the resulting implant to gain access to a substantial number of high-value organizations including U.S. federal agencies and major private-sector firms.
This account is correct as far as it goes. It is also incomplete, in a way that obscures part of the lesson most relevant to modern security operations.
The post-implant chapter
The implant — known publicly as SUNBURST — was an initial-access mechanism. It provided the attacker with a foothold on systems running Orion. The work of converting that foothold into a meaningful intelligence operation was performed by a second-stage capability operating against the victim's identity and cloud infrastructure. The attacker forged SAML tokens that allowed them to impersonate users in Microsoft 365 environments, harvested OAuth grants to gain persistent access to mail and file data, and modified federation trust configurations to maintain access even when individual credentials were rotated.
This second chapter is the chapter where most of the actual damage was done. The initial implant is what gave the attacker access to the right place. The identity-layer techniques are what gave them access to the right data, for long enough to extract it.
Detection came from an unexpected place
The detection narrative is similarly instructive. The SUNBURST implant had been operating undetected for months by the time it was discovered. The chain of events that led to disclosure began with a security engineer at FireEye noticing that a new authenticator had been registered for an employee's account without the employee's knowledge. Pursuing that anomaly led to the broader recognition of an active compromise, which in turn led to the discovery of the SolarWinds implant.
The takeaway is consequential. The detection point was not at the network layer or in the endpoint telemetry — it was at the identity layer, where an unexpected change to authentication metadata prompted a human analyst to investigate. The same identity-layer activity that produced the breach also produced its eventual discovery.
What this implies for 2026 defenders
The supply-chain dimension of the story has been thoroughly absorbed by the industry. SBOM standards, signed-build initiatives, and provenance frameworks have all advanced significantly since 2020. The identity dimension has been less thoroughly absorbed. Few organizations today maintain a current inventory of OAuth grants across their workspace tenants. Fewer still monitor federation trust configurations for unexpected changes. Even fewer have implemented continuous review of authenticator registrations across the population.
The MITRE ATT&CK framework documents the relevant techniques in detail — the SAML token forgery technique that the SolarWinds actor used is catalogued explicitly, as are the OAuth abuse patterns that became prominent after. The CISA Zero Trust Maturity Model reflects the post-SolarWinds reorientation toward identity-first security architectures. The NIST Cybersecurity Framework 2.0 govern function similarly emphasizes the identity-layer assumptions that any modern security program must address.
The continuing relevance of the case
Five years after the initial disclosure, the SolarWinds case continues to be cited in security literature primarily as a supply-chain example. The identity-layer dimension deserves equal attention. A defender who internalizes both lessons asks two questions in parallel: how do I know my build dependencies are trustworthy, and how do I know which OAuth grants and federation trusts exist in my environment? Either question alone is incomplete. A broader analysis of SaaS breaches argues that the same pattern recurs across many subsequent incidents.
The structural recommendation that follows is straightforward: continuous visibility into the identity and OAuth surface is now a baseline expectation, not an advanced control. Discovery tools such as Waldo Security's SaaS Discovery exist specifically to provide this visibility, including across systems that do not federate with the corporate IdP.
For a current view of your OAuth grant inventory and identity-layer exposure, a demonstration can be arranged.



Comments