Federal cyber experts spent three years reviewing Microsoft’s Government Community Cloud High and concluded there was “a lack of confidence in assessing the system’s overall security posture.” One reviewer called the security documentation “a pile of shit.” Yet FedRAMP—the Federal Risk and Authorization Management Program—authorized the product in December 2024 anyway. Not because Microsoft fixed the issues. Because federal agencies were already using it, and reversing course would cause operational chaos. This is security theater at its most dangerous: compliance became a rubber stamp for a product the government couldn’t even assess.
A ProPublica investigation published today exposes the breakdown. Microsoft was central to two major federal breaches—the 2020 SolarWinds attack and a 2023 Chinese hack of GCC—yet received authorization despite documented security failures. The pattern is clear: when vendors achieve enough market penetration, security standards become optional.
Microsoft Couldn’t Document Its Own Security
FedRAMP requested detailed data flow diagrams showing how data travels through Microsoft’s systems and where encryption occurs. This is standard documentation—AWS GovCloud and Google Cloud provide it routinely. Microsoft took months to respond with incomplete white papers that omitted critical encryption points. Reviewers stated they “never got past Exchange” and had “no visibility inside.” One called Microsoft’s architecture a “pile of spaghetti pies”—data taking unnecessary detours “by bus, ferry, and airplane” instead of direct encryption paths.
Microsoft acknowledged it faced “a challenge related to illustrating the volume of information being requested in diagram form.” Translation: Microsoft’s legacy architecture is so complex even Microsoft can’t document it. The final assessment noted “lack of proper detailed security documentation.” Security that can’t be documented can’t be audited. Security that can’t be audited can’t be trusted.
The contrast matters. AWS and Google built government clouds from scratch with clean, documentable architectures. Microsoft is retrofitting security onto decades-old commercial Microsoft 365 infrastructure. The result: competitors can prove their security through documentation. Microsoft asks FedRAMP to trust them despite inability to provide evidence. One approach is verifiable. The other is faith-based.
Approved Because Agencies Already Used It
FedRAMP didn’t approve GCC High because Microsoft resolved security concerns. They approved it because multiple federal agencies—especially the Justice Department—were already using the product. Revoking authorization would create compliance violations and operational disruption. Consequently, the security assessment became post-hoc justification for existing deployment.
The timeline tells the story. Justice deployed GCC High in early 2020, before FedRAMP review began in April 2020. FedRAMP spent three years trying to get documentation from Microsoft. In October 2023, FedRAMP Director Brian Conrad told Microsoft the engagement was ending due to unresolved gaps. A new director restarted the review in August 2024 despite the same issues. December 2024: approved with “conditions for continued oversight”—meaningless when FedRAMP operates with 24 employees.
This exposes backwards logic. Normal process: product proves it’s secure, gets approved, agencies use it. Microsoft’s process: agencies use product, creates political pressure, gets approved despite security concerns. Once a vendor achieves enough deployment penetration, they become “too big to fail.” Security becomes secondary to avoiding disruption.
Microsoft’s Track Record: SolarWinds to Chinese Hacks
Context matters. This approval came after Microsoft products were central to two major federal cyberattacks. In 2020, Russian hackers exploited a Microsoft vulnerability in the SolarWinds breach—Microsoft knew about the flaw since 2017 but didn’t fix it despite internal warnings. The breach affected the Justice Department, National Nuclear Security Administration, and multiple agencies. Microsoft never took responsibility, blamed federal agencies for not pushing harder.
In summer 2023, during GCC High’s security review, Chinese hackers breached the lower-tier GCC. They exploited what security experts called “a fundamental gap in Microsoft’s cloud,” compromising Commerce Secretary Gina Raimondo’s emails and 25 organizations. Senator Ron Wyden stated “Microsoft must be held responsible.” FedRAMP approved GCC High 15 months later.
Any other vendor with two major breaches in four years would be disqualified. Microsoft got approved. Pattern recognition matters. Microsoft has a documented history of security failures affecting federal systems. The fact that FedRAMP authorized GCC High after—and during—these breaches shows vendor track record doesn’t matter when the vendor is too embedded to remove.
Budget Cuts Enabled Rubber-Stamp Approvals
FedRAMP’s budget was slashed to $10 million annually—lowest in a decade—with only 24 employees. The director stated these employees are “entirely focused on delivering authorizations” at record pace, not conducting rigorous reviews. Furthermore, with skeleton staff and minimal budget, FedRAMP transformed from genuine security oversight to rubber-stamp operation approving products quickly to meet quotas.
Tony Sager, former NSA CISO, calls it “security theater.” You can draw a direct line from budget cuts to security failures. The same agencies demanding cloud vendors meet “gold standard” security controls gutted the organization responsible for validating those controls. Moreover, security theater costs less than actual security, until something breaks.
Post-authorization monitoring is essentially non-existent. GCC High’s approval included “conditions for continued oversight.” However, 24 people can’t oversee hundreds of authorized cloud products. Vendors know FedRAMP lacks resources to enforce conditions or revoke authorizations. The oversight is performative.
What Else Wasn’t Disclosed?
After FedRAMP authorized GCC High, the Justice Department discovered Microsoft used China-based engineers to maintain the system—violating federal rules prohibiting non-U.S. citizens from accessing sensitive IT systems. Microsoft’s written security plan “did not mention foreign engineers.” The government learned about this from ProPublica’s investigation, not from FedRAMP or Microsoft. Microsoft ended the practice only after media exposure.
This revelation shows Microsoft’s documentation failures weren’t just incomplete—they actively hid material risks. If a multi-year FedRAMP security review couldn’t identify foreign engineers working on sensitive federal systems, what else did reviewers miss? Microsoft’s security plan omitted this information entirely. Documentation gaps weren’t about complexity—they were about disclosure.
Key Takeaways
- FedRAMP authorization doesn’t guarantee security – Microsoft’s GCC High was approved despite reviewers stating “lack of confidence in assessing security posture.” The certification became a rubber stamp, not a validation.
- Market dominance trumps technical merit – Microsoft got approved because agencies already used the product, not because it met security standards. Deployment momentum overrode technical assessment.
- Documentation failures hide material risks – Microsoft couldn’t provide basic security documentation that competitors routinely submit. Even more concerning: they omitted foreign engineers entirely from security plans.
- Budget cuts turned oversight into theater – FedRAMP operates with $10M budget and 24 staff, focusing on “delivering authorizations” quickly rather than rigorous review. Post-authorization monitoring is non-existent.
- Vendor track record doesn’t matter for incumbents – Microsoft was central to two major federal breaches (2020 SolarWinds, 2023 Chinese GCC hack), yet still received authorization for higher-security GCC High.
The broader implication: compliance frameworks break down when political and budgetary pressure outweighs technical standards. “FedRAMP authorized” means a vendor jumped through bureaucratic hoops. It doesn’t mean “actually secure.” Consequently, organizations relying on federal security certifications as proof of vendor security should conduct independent assessments. Checking boxes isn’t the same as preventing breaches.
