Microsoft Cloud Called "A Pile of Shit."
The Government Approved It Anyway.

The email, quoted in a ProPublica investigation published this week, was short and to the point. After years of failed security reviews, confused documentation, and a mounting pile of unanswered questions about how Microsoft's cloud actually protects the US government's most sensitive secrets, a federal cybersecurity evaluator finally wrote what everyone on the team was thinking.

"The package is a pile of shit."

That evaluator was part of FedRAMP - the Federal Risk and Authorization Management Program, the agency whose entire job is to make sure cloud products used by the US government are actually secure. The product in question was Microsoft's Government Community Cloud High, or GCC High: a suite of cloud services marketed to protect information classified as so sensitive that leaking it "could be expected to have a severe or catastrophic adverse effect" on US operations and national security.

FedRAMP authorized it anyway.

The ProPublica investigation, based on internal FedRAMP memos, logs, emails, meeting minutes, and interviews with seven former and current government employees and contractors, is one of the more damning pieces of accountability journalism in recent memory on the intersection of big tech, government procurement, and national security. It traces a five-year chain of institutional failures that left key federal agencies - including the Justice Department, Energy Department, and the broader defense sector - running sensitive data through a cloud system whose security architecture nobody in the government could actually verify.

What Is GCC High, and Why Does It Matter?

Most people have never heard of GCC High. That's by design - it's a backend infrastructure product, not a consumer app. But understanding what it is makes the story considerably more alarming.

GCC High is Microsoft's Government Community Cloud, tier "High" - the designation reserved for contractors and agencies handling Controlled Unclassified Information under the International Traffic in Arms Regulations (ITAR) and Export Administration Regulations (EAR). In plain English: weapons systems data, export-controlled defense technology, nuclear program information, classified law enforcement files, and the personal records of government employees with security clearances.

It's a version of Microsoft's standard Office 365 suite - Teams, Exchange Online, SharePoint, OneDrive - but supposedly hardened to meet the government's most rigorous security requirements. The key word is "supposedly." The central revelation of the ProPublica investigation is that nobody in the government could verify that hardening actually worked, because Microsoft never provided complete documentation of how its data encryption operates at every point in the system.

This is not a trivial paperwork problem. Data flow diagrams - the documents Microsoft failed to provide - are the map of where sensitive data travels through a cloud system and where it becomes encrypted and decrypted. Without those maps, cybersecurity reviewers cannot determine whether data is exposed at any point in transit. They cannot verify what happens to information as it hops between Microsoft's servers. They cannot assess the attack surface for nation-state hackers who specifically target these transit points.

The architecture of Microsoft's legacy cloud, built on decades of accumulated code from the Windows and Office product lines, is particularly complex. One FedRAMP reviewer described it to ProPublica as a "pile of spaghetti pies" - data traveling from Washington to New York via bus, ferry, and airplane rather than a clean Amtrak ride. Each detour is a potential point of compromise if encryption isn't applied properly. And without the documentation, nobody could verify it was.

"The data's path from Point A to Point B was like traveling from Washington to New York with detours by bus, ferry, and airplane rather than just taking a quick ride on Amtrak. And each one of those detours represents an opportunity for a hijacking if the data isn't properly encrypted." - Former FedRAMP reviewer, speaking to ProPublica on condition of anonymity

Five Years of Stalling, Excuses, and "Rock Fetching"

The story begins in 2020, when the Justice Department decided to move to GCC High and effectively dragged it onto FedRAMP's radar. At the time, the standard path to FedRAMP authorization involved independent third-party assessors vetting the product and FedRAMP completing a final review. This system had a known weakness: the third-party firms were hired and paid by the companies being assessed, creating a structural conflict of interest. But it was the system in place.

FedRAMP's team quickly identified the problem: Microsoft had not provided adequate data flow diagrams for GCC High. They started with a narrow request - just show us how Exchange Online, the email product, handles encryption in transit. This was presented as a "litmus test." If Microsoft could document this basic piece, they could work from there.

Microsoft took months to respond. When it did, it submitted a white paper that described GCC High's encryption "strategy" at a high level but omitted the operational details FedRAMP needed: specifically, where in the data journey encryption is applied and where it is removed. These "handoff points" are precisely where hackers concentrate their efforts. The white paper said Microsoft encrypted data. It did not show FedRAMP the mechanism.

This pattern repeated across five years. FedRAMP would request. Microsoft would delay. Microsoft would return with something FedRAMP deemed insufficient. FedRAMP would pull its punches rather than reject the application outright. The gap kept yawning.

John Bergin, the Microsoft official who became the government's primary point of contact, defended the company's approach to ProPublica, calling FedRAMP's requests for diagrams a "rock fetching exercise" and blaming the agency for a lack of standardized templates.

"We were maybe incompetent in how we drew drawings because there was no standard to draw them to. Did we not do it exactly how they wanted? Absolutely. There was always something missing because there was no standard." - John Bergin, Microsoft government cloud official, to ProPublica

The explanation strains credibility. Amazon Web Services and Google Cloud - Microsoft's direct competitors in the government cloud market - routinely provided the level of detail FedRAMP sought. Tony Sager, who spent more than three decades as a computer scientist at the National Security Agency before becoming an executive at the Center for Internet Security, told ProPublica the fundamental issue is architectural. Amazon and Google built their cloud systems from the ground up with modern security isolation in mind. Microsoft's cloud was assembled around legacy code dating back decades, code that was never designed for the kind of strict security compartmentalization a government environment demands.

Microsoft's own engineers, according to two people involved in building cloud services for federal customers, had struggled over the years to map the architecture of their own products. The systems were simply too complex and too old to generate clean data flow diagrams - not because Microsoft was hiding something, but because the information may not have existed in any clean, documentable form.

Two Major Hacks, Zero Consequences for Approval

The review didn't happen in a vacuum. Twice during the five-year FedRAMP review, Microsoft products were at the center of catastrophic cyberattacks against the US government - attacks that, by any reasonable standard, should have triggered a harder look at whether GCC High could be trusted with even more sensitive data.

The first was SolarWinds, the Russian state-sponsored campaign discovered in late 2020. While the initial vector was SolarWinds' own software, Russian intelligence - specifically the SVR's Cozy Bear group - used that access to exploit a long-standing weakness in a Microsoft product to move deeper into federal networks. The breach reached the National Nuclear Security Administration, the agency that manages the US nuclear weapons stockpile. It compromised the Justice Department. It sat undetected for months. ProPublica had previously reported that Microsoft had refused to fix the underlying flaw for years, despite internal warnings from its own engineers.

The second breach came in 2023. Chinese state-sponsored hackers infiltrated Microsoft's Azure cloud infrastructure and used forged authentication tokens to access the email accounts of a Cabinet secretary and dozens of senior US officials. The attack was notable for its precision - the hackers specifically targeted high-value diplomatic and policy targets at a moment of escalating US-China tension. It was only discovered because a Microsoft customer happened to have the right logging tier enabled and spotted the anomalous access. Most GCC High customers would not have had that logging capability.

Both attacks were publicly known before FedRAMP's late-2024 authorization decision. Neither changed the outcome.

"This is not a happy story in terms of the security of the US." - Tony Sager, former NSA computer scientist, now at the Center for Internet Security

The SolarWinds investigation led to genuine consequences - executive orders on zero-trust security, new requirements for software bill of materials, and the Biden administration's Cyber Executive Order of 2021. The Azure breach led to Microsoft's "Secure Future Initiative" and a report from the Cyber Safety Review Board that excoriated the company's security culture in remarkable terms.

None of this stopped GCC High's authorization. By the time FedRAMP formally approved GCC High in late 2024, the reviewers concluded they effectively had no choice. The product was already deployed at the Justice Department, the Energy Department, and across major defense contractors. The political and operational cost of withdrawing authorization - forcing a migration away from a product already running core government functions - was simply too high. The review ended not with an answer to the original questions but with a "buyer beware" notice attached to the authorization. Agencies were warned to consider the risks. They were not told to stop using the product.

The Revolving Door and the Rubber Stamp

The deeper you go into the ProPublica investigation, the more the individual failures start to look like system design rather than accident. A program structurally underfunded and understaffed, evaluating a company that is also its largest single source of government cloud business, using third-party assessors paid by the company being assessed, with an authorization marketplace that rewards being "in process" almost as much as being fully certified. The incentives were never aligned toward rigorous security.

One data point: Melinda Rogers, the Justice Department's deputy chief information officer who made the 2020 decision to deploy GCC High across the DOJ, was hired by Microsoft in 2025. Through a spokesperson, Rogers "stands by the rigorous evaluation" that contributed to her authorization decision. Microsoft says there was "absolutely no connection" between her hiring and the GCC High process. The timeline suggests the two parties developed a productive relationship during five years of review.

The third-party assessment system produced its own dysfunction. Coalfire and Kratos, the firms hired by Microsoft to independently assess GCC High, told FedRAMP through back-channel communications that they were unable to get the full picture of the product's security architecture from Microsoft. This is the system working as designed - the backdoor exists precisely because assessors often cannot bring negative findings to the company paying their bills. The existence of the backdoor is also an implicit acknowledgment that the formal assessment process regularly produces incomplete results.

"For years, the FedRAMP process has been equated with actual security. This is not security. This is security theater." - Tony Sager, former NSA computer scientist and executive at the Center for Internet Security

The authorization FedRAMP ultimately issued is technically unprecedented. It includes what amounts to a disclaimer - a "buyer beware" notice telling agencies to weigh the unresolved security questions before deploying the product. No other FedRAMP authorization has come with this kind of caveat attached. The authorized product is being used to protect nuclear secrets and law enforcement records while simultaneously carrying a formal notice that its security cannot be fully vouched for.

Microsoft's response to all of this is a masterclass in corporate non-denial. The company "stands by its products and the comprehensive steps" taken to meet security requirements. It says it provided "comprehensive documentation" throughout the review and "remediated findings where possible." It acknowledges the "yearslong confrontation" with FedRAMP but attributes the failure to produce adequate diagrams to the lack of a standardized template rather than to anything intrinsic to the product.

DOGE Finishes the Job

There's a dark coda to all of this. The ProPublica investigation was published on March 18, 2026. By that point, the agency being criticized for failing to properly vet Microsoft's cloud security had already been largely dismantled.

FedRAMP was an early target of the Department of Government Efficiency - the Musk-backed advisory body that has moved through federal agencies cutting staff and budgets with limited regard for downstream consequences. FedRAMP's workforce has been reduced to approximately 24 people. Its annual budget stands at $10 million - its lowest level in a decade. The agency's own director has acknowledged that remaining staff are "entirely focused on delivering authorizations at a record pace" and that the program operates with "an absolute minimum of support staff" and "limited customer service."

In other words: less scrutiny, more approvals. The agency responsible for ensuring the security of cloud products used by the entire federal government is simultaneously more productive, by the metric of authorizations issued, and less capable, by any reasonable measure of depth of review.

This matters enormously for what comes next. The Trump administration has pushed an aggressive AI adoption agenda across federal agencies, explicitly encouraging the use of cloud-based AI tools that will have access to precisely the kind of sensitive data GCC High is supposed to protect. These AI systems ingest, process, and retain large volumes of government information. Their security depends entirely on the security of the cloud infrastructure they run on. And the agency certifying that security is now a skeleton crew chasing throughput metrics.

Former FedRAMP employees who spoke to ProPublica were blunt. The program "now is little more than a rubber stamp for industry." The implications "are far-reaching" given the administration's push to load sensitive government data into AI systems. The pattern established by GCC High - deploy first, certify later, never fully answer the security questions, authorize because removal is too costly - is likely to repeat.

"The package is a pile of shit." - Internal FedRAMP evaluation of Microsoft GCC High, late 2024. The program authorized it the same year.

The Second-Order Problem: What Happens When AI Runs on This?

The immediate story is about Microsoft and GCC High. The larger story is about what happens when a broken certification process meets an accelerating government AI adoption agenda.

The Biden administration's AI Executive Order and the Trump administration's follow-on America's AI Action Plan both explicitly encourage federal agencies to adopt cloud-based AI tools. These tools - from Microsoft Copilot to various third-party AI assistants built on cloud infrastructure - process sensitive government data at scale. They are memory-persistent in ways traditional software is not: they store conversation history, learn from interactions, and retain contextual information across sessions.

When those AI tools run on GCC High, whose encryption architecture cannot be fully documented, the risk surface multiplies. A nation-state actor who can access data in transit in the underlying cloud infrastructure gains access not just to static documents but to the distilled intelligence of government employees' AI interactions: their questions, their concerns, their strategic thinking. The AI layer turns a data breach into a cognitive breach.

This is not speculative. The 2023 Azure breach demonstrated that Microsoft's government cloud is a high-priority target for sophisticated adversaries. Chinese intelligence specifically sought email correspondence from senior diplomatic officials. That breach accessed communications. A future breach of a cloud running AI tools with memory would access something closer to the working mind of the government officials using them.

The FedRAMP certification framework was not designed for this threat model. It predates modern AI deployment at scale. Its data flow diagram requirements were built around the assumption that data flows are mappable static paths. In an AI system with persistent memory and continuous inference, the "data flow" is the entire computational history of the system. Nobody has built a standard for documenting that, and FedRAMP - now a skeleton crew - is in no position to demand one.

Microsoft is not uniquely culpable here. Every major cloud provider benefits from a certification system that is faster than it is deep. Amazon Web Services holds FedRAMP authorizations for hundreds of products. Google Cloud has expanded aggressively in the government market. The incentive for any of them to allow rigorous, time-consuming security review is limited when the alternative - deploying ahead of full authorization via the "agency path," getting embedded, and becoming too costly to remove - has proven so reliably successful.

The DOJ's Melinda Rogers proved the model in 2020. The Justice Department adopted GCC High on the agency path. GCC High spread to other agencies. By late 2024, removal was politically and operationally impossible. The "buyer beware" caveat on the authorization is the FedRAMP equivalent of "this vehicle was approved without a full safety inspection, drive accordingly." The vehicle is now carrying the nuclear codes.

What Comes Next - And What Should

The ProPublica investigation has created pressure that may actually move some levers. The revelations arrive as the Justice Department is actively pursuing cyber-fraud cases against government contractors who misled agencies about security compliance. In December 2025, the DOJ indicted a former Accenture employee for allegedly providing false security certifications. That prosecution was framed around exactly the kind of conduct the GCC High story describes - companies representing compliance they could not actually demonstrate.

Whether the same standard applies to Microsoft is an open question. The GCC High situation differs from fraud in important ways: Microsoft didn't certify false compliance so much as it failed to provide complete documentation while benefiting from a review process that was structurally reluctant to reject a product already in deployment. The FedRAMP team's own decisions - to keep accepting partial answers, to allow agencies to deploy before authorization, to ultimately sign off under the logic of "too embedded to remove" - are as culpable as Microsoft's documentation failures.

What genuinely effective reform would require is several things the current administration shows no appetite for. FedRAMP needs adequate staffing and budget to conduct actual deep-dive reviews, not throughput-optimized rubber-stamping. The "agency path" to deployment needs to be structurally separated from the path to FedRAMP authorization - agencies should not be able to deploy a product commercially across their infrastructure while its security review is pending. Third-party assessors need to be paid by the government, not by the companies being assessed. And the entire framework needs to be rebuilt for AI-era threat models where data flows are not static paths but continuous inference processes.

None of this is technically difficult. Regulatory frameworks adequate to the moment exist - they just require political will and budget that is currently moving in precisely the opposite direction. DOGE's cuts to FedRAMP are not the result of a finding that FedRAMP was doing too much. They are the result of a generic cost-cutting mandate applied to a small federal program without apparent consideration of what would happen to government cybersecurity in its wake.

The answer to "what should come next" is fairly obvious. The answer to "what will actually happen" is considerably darker. Microsoft's GCC High will continue hosting the most sensitive government data. FedRAMP will continue issuing accelerated authorizations with a skeleton crew. More cloud-based AI products will receive certifications they have not been fully evaluated for. And somewhere in that spaghetti pile of legacy code, data will continue moving from server to server along paths nobody in the government can fully map.

At some point, someone else will find one of those detours. The history suggests they'll be state-sponsored, patient, and well-resourced. And the history also suggests that when it happens, Microsoft will defend its products as having met the requirements - and FedRAMP will have a paper trail showing it authorized them.

Sources: ProPublica (Renee Dudley / Doris Burke, March 18, 2026), Ars Technica, FedRAMP public records, GAO reports, court filings. All quotes attributed to named or anonymized sources within the ProPublica investigation.