FedRAMP Authorized: How Compliance Theater Kept Microsoft's Cloud in Federal Hands

A ProPublica investigation published this week reveals that federal cybersecurity experts used language like “a pile of shit” to describe Microsoft’s cloud security posture in internal communications, yet the company’s products maintained their FedRAMP authorization throughout. That tension, between what experts privately concluded and what the authorization framework publicly declared, is worth pulling apart carefully, because it exposes something structural rather than incidental.

What FedRAMP Actually Certifies

FedRAMP, the Federal Risk and Authorization Management Program, was created by an OMB memo in 2011 and codified in law through the FedRAMP Authorization Act in 2022. The program’s core promise is simple: a cloud service provider gets assessed once, and that assessment can be reused by any federal agency. “Do once, use many times.”

Authorization runs through one of two tracks. The Joint Authorization Board (JAB), composed of the CIOs from DoD, DHS, and GSA, handles the most rigorous tier. Agency ATOs (Authorities to Operate) let individual agencies grant authorization on their own. Both tracks require vendors to hire Third-Party Assessment Organizations (3PAOs) to audit their compliance against hundreds of NIST SP 800-53 controls.

The output is a package: a System Security Plan running into the thousands of pages, a Security Assessment Report from the 3PAO, and a Plan of Action and Milestones (POA&M) documenting known vulnerabilities and the timeline to fix them.

The POA&M is where authorization starts to decouple from security. A vendor can document serious vulnerabilities, commit to a remediation timeline, and remain fully authorized while those vulnerabilities sit open. This is by design. The framework assumes that documented risk, acknowledged and tracked, is preferable to the alternative of revoking authorization and forcing agencies to find alternatives under duress. In practice, it creates a system where known problems can persist indefinitely behind a wall of paperwork.

The Record Behind the Authorization

The specific record behind Microsoft’s cloud authorization is damning. In summer 2023, a Chinese threat actor tracked as Storm-0558 accessed the email accounts of roughly 25 organizations, including officials at the US State Department and Department of Commerce. The attack lasted approximately a month before detection. It worked because the attacker obtained a Microsoft consumer signing key (an MSA key) that should never have been accessible to or usable in enterprise authentication contexts, and then forged Azure Active Directory tokens with it.

Microsoft’s own post-incident analysis was unable to definitively explain how the consumer signing key ended up in a crash dump accessible to the attacker. That is not a minor gap. Not knowing how your most sensitive cryptographic material was exfiltrated is a fundamental failure of key management and audit logging.

The Cyber Safety Review Board’s report, released in April 2024, went further. The CSRB concluded that the intrusion was preventable, that Microsoft’s security culture was inadequate, and that the company had made a “cascade of security failures” across key management, token validation, and incident logging. The board recommended Microsoft pause adding new features until security posture improved, language that represented an unusual degree of directness from a government body reviewing a vendor on whom the government heavily depends.

The roots of the problem go back further. When the SolarWinds attack unfolded in 2020, attackers pivoted from on-premises environments into cloud infrastructure by forging SAML tokens, a technique sometimes called Golden SAML. A Microsoft security researcher named Andrew Harris had reportedly identified this attack surface years earlier and raised internal concerns. The fix would have broken backward compatibility with legacy Active Directory setups, and it was delayed. That delay contributed to the scale of the SolarWinds compromise, which itself affected multiple federal agencies.

The Structural Misalignment

None of this caused Microsoft to lose its FedRAMP authorization. Understanding why requires understanding the incentive structure that surrounds the authorization decision.

The first pressure is vendor lock-in at scale. Microsoft holds something approaching a monopoly on federal productivity infrastructure. Active Directory runs identity management across most agencies. Exchange and Outlook handle email. Teams runs internal communication. Azure increasingly hosts workloads. The licensing footprint runs to billions of dollars annually. Revoking authorization would not just inconvenience agencies; it would require migrating identity management, email, collaboration, and cloud infrastructure simultaneously, across systems that were never designed to be separated. No federal CISO wants to be responsible for triggering that migration.

The second pressure is the 3PAO payment model. Third-party assessment organizations are hired and paid by the vendors they assess. This is a textbook conflict of interest, and FedRAMP has never resolved it. The 3PAO industry depends on maintaining relationships with the major cloud vendors to stay in business. Findings that could threaten a vendor’s authorization threaten the 3PAO’s revenue stream.

The third pressure is the POA&M escape valve. Because the framework tolerates documented open vulnerabilities, there is no clear line at which problems become authorization-threatening. Microsoft can acknowledge failures, commit to timelines, and remain authorized. The framework has no mechanism that says: this class of failure is disqualifying regardless of remediation timelines.

The fourth, and most corrosive, is the asymmetry of consequences. If a federal official approves a vendor with known problems and nothing bad happens, nothing happens to that official. If they revoke authorization and the resulting chaos causes operational failures, the official wears those failures. The incentive structure strongly favors approving and documenting risk over taking the career-ending step of revoking authorization for a deeply embedded vendor.

What Security-Driven Authorization Would Require

FedRAMP’s documentation-centric model made sense as a starting point in 2011, when the question was simply whether cloud was acceptable at all for federal use. Fifteen years later, the question is different: can the framework actually distinguish between a secure cloud offering and an insecure one from the same vendor?

A framework with teeth would look different in several ways. Continuous, automated adversarial testing against production systems would replace point-in-time 3PAO audits. The 3PAO payment model would move to an escrow or government-administered fund to eliminate direct vendor payment. Certain categories of failure, particularly failures in cryptographic key management and authentication token validation, would trigger mandatory review with a defined path to suspension. Incident disclosure requirements would mandate notification within hours, not weeks, when government customer data is involved.

Most importantly, the framework would need to acknowledge that “too embedded to revoke” is not a security posture, it is the absence of one. If a vendor’s authorization cannot be revoked because the cost of switching is too high, then the authorization has no meaning. It is a certificate of dependency, not a certificate of security.

The Pattern Repeats

What ProPublica has documented is not a story about one bad breach or one bad decision. The experts who privately described Microsoft’s cloud in blunt terms and then signed off on its continued authorization were not being hypocritical; they were responding rationally to a set of incentives that had been designed to produce exactly that outcome.

Microsoft launched its Secure Future Initiative after the CSRB report. Brad Smith testified before Congress and committed to prioritizing security. These are real commitments with real engineering investment behind them, and the progress reports show genuine internal reorganization. But Microsoft has made similar commitments after previous incidents, including after SolarWinds.

The cycle will continue as long as the authorization framework makes lock-in a stronger force than accountability. When the cost of switching exceeds the cost of tolerating insecurity, the rational choice for everyone inside the system is to tolerate the insecurity and file the paperwork. That is not a flaw in how individual officials exercised judgment. It is the program working exactly as its incentive structure demands.

FedRAMP was designed to lower the barrier to cloud adoption in government. It succeeded at that. Whether it was ever really designed to enforce security is a different question, and the internal communications that ProPublica obtained suggest that at least some of the experts running it knew the answer.