Agencies buy a cloud provider’s security culture whether or not the contract mentions it

The week

On April 2, 2024, the Department of Homeland Security published the Cyber Safety Review Board’s report on the 2023 compromise of Microsoft Exchange Online, the cloud email service that many US government agencies and companies rely on. The report was dated March 20. The board is a federal panel set up to study major cyber incidents after the fact, so that everyone can learn from them.

The board was created under a May 2021 executive order on improving the nation’s cybersecurity. It drew members from government and industry. Its earlier reviews had covered the Log4j software vulnerability and the Lapsus$ extortion group. DHS Secretary Alejandro Mayorkas announced the Microsoft review in August 2023, and widened its scope to cover risks to cloud identity and authentication across providers, rather than at one company alone.

The first sign of the intrusion had come from a customer rather than from Microsoft. In mid-June 2023, the State Department’s security team noticed unusual mailbox access in its logs and raised the alarm. It had built an alert on a specific log event that recorded when mail items were accessed. That event was available to State because it paid for a premium license tier.

Microsoft disclosed the intrusion publicly on July 11, 2023. The next day, CISA and the FBI issued an advisory urging organizations to enable that same kind of logging and to watch for anomalous mailbox access.

The attackers were a China-linked group that Microsoft tracks as Storm-0558. Their method was striking. They used a stolen Microsoft consumer signing key to forge tokens. A signing key is a secret that a service uses to vouch for someone. A token is the digital pass that proves you have logged in. With the stolen key, the intruders could make passes that looked genuine, and use them to read email at organizations including US government agencies.

The scale was significant. The board reported that the intruders accessed email accounts at 22 organizations and more than 500 individuals. Among them were senior US officials, including the Commerce Secretary and the US ambassador to China. The State Department alone lost about 60,000 emails.

The board did not soften its conclusions. It found the intrusion preventable and said Microsoft’s security culture was inadequate and required an overhaul. It described a cascade of avoidable errors. Microsoft still had not determined how the key was stolen. The board also noted a separate intrusion, disclosed by Microsoft in January 2024, in which a Russian intelligence group had accessed the email of Microsoft’s own senior staff. To the board, the second case suggested the problems were not confined to one incident.

The report also dealt with how the story had been told. In September 2023, Microsoft had published an explanation that pointed to a crash dump, a snapshot of memory a computer saves when a program fails, as the likely route by which the key escaped. That explanation had not been corrected until March 12, 2024, although Microsoft had found no evidence for it.

That September account had been detailed. It said a 2021 crash of the consumer signing system had produced a crash dump that, because of a software flaw, contained the key. The dump was said to have moved into a debugging environment connected to the corporate network, where an engineer’s account was later compromised. Each step was plausible. The board found that Microsoft could not show that any of them had actually happened.

Microsoft had not waited for the report to announce changes. In November 2023 it launched its Secure Future Initiative, a company-wide security program. The board’s findings arrived against that backdrop, and its call for a public plan with timelines read as a judgment that the initiative alone was not enough.

The board asked Microsoft to publish a plan, with timelines, for fundamental security reforms. It also looked beyond one company. It recommended default audit logging across cloud providers, meaning that the basic records of who did what should come as standard rather than as an extra. It also recommended updates to FedRAMP, the federal program that approves cloud services for government use, including special reviews of authorized services after high-impact incidents.

Microsoft’s own September 2023 account described how signing keys can leak through ordinary engineering. The board’s report went further, in a direction that matters more to buyers. Its central finding was about culture: how a provider decides between security and everything else.

An agency’s FedRAMP package, contract and license terms describe controls. None of them describes culture, and yet every agency on a major cloud platform depends on it. Culture cannot be audited directly. It does leave evidence, and the report shows where to look.

The evidence falls in three places: how a provider treats its most critical secrets over time, how it detects and discloses its own failures, and what it ships as the default. Each points to a question an agency can put in a solicitation or renewal. And although this case involved federal agencies, every bank, hospital system and insurer that runs on a major cloud platform is in the same position.

The sections below first explain how keys and tokens work and how agencies buy cloud services, since both shape what a buyer can see. They then take the three kinds of evidence in turn: secrets, disclosure and defaults. The last three sections cover what the shift to cloud does to accountability, how to run a renewal that collects this evidence, and the questions to settle before the next one.

Keys, tokens and a stale secret

Start with the cloud itself. When an organization moves its email to “the cloud,” it stops running its own email servers and instead rents the service from a provider such as Microsoft. The provider runs enormous shared systems that serve many customers at once. Each customer’s data is kept separate by software rules rather than by physical walls. That arrangement is efficient and usually more secure than a small organization could manage alone. It also means that a single weakness at the provider can affect many customers at the same time.

Next, identity. Every time someone opens their mailbox, the service needs to know who they are. Rather than checking a password on every click, the system issues a token after login: a small digital pass that says, in effect, “this person is who they claim to be, signed by us.” The signature comes from a signing key, a long secret number held by the provider. Anyone who holds that key can make tokens the system will believe.

A hotel key card system works the same way. The front desk has a master encoder. If someone steals the encoder, they can cut cards for any room, and the doors will open as if the cards were genuine. The locks are working perfectly. The problem is that the thing they trust has been copied.

Finally, rotation. Because keys can leak, good practice is to replace them regularly, so that any stolen copy soon stops working. This is called key rotation. Re-keying the hotel encoder every few months leaves a thief who copied the old one holding something useless.

With that vocabulary, the story is easier to follow. A key that should have been replaced was still in use. It was a consumer key, meant for personal accounts, yet flaws in checking tokens let it be accepted for enterprise email. And the attackers used it to walk through doors that should have stayed shut.

Why one consumer key opened enterprise mail

Microsoft runs two broad identity systems. One serves consumer accounts, such as personal email. The other, now called Entra ID, serves organizations. Each signs its own tokens with its own keys. A well-built service should accept an enterprise token only if an enterprise key signed it.

Microsoft’s own accounts in 2023 said that check was missing in the path the attackers used. Enterprise mail relied on a common way of looking up signing keys that included consumer keys, and the code did not confirm which system a key belonged to. A forged token signed with the consumer key passed.

Two failures had to coincide: a stale key that should have expired, and a validation gap that let it cross from one system to another. Either alone might have been contained. Together they let one stolen secret reach government mailboxes. That is typical of serious incidents. They rarely rest on one mistake, and the defenses that matter are the ones that make each mistake less likely to line up with the next.

Why the logs decided who noticed

A forged token is hard to spot at the front door, because it looks valid. The intrusion becomes visible only later, in what the intruder does: which mailboxes are opened, from which addresses, at what times. Spotting that requires a record of mailbox access, kept long enough to compare with normal patterns. State had that record and had written an alert against it. Agencies without it had no comparable signal, whatever their other controls. The same holds for any organization on a shared platform. Its ability to detect misuse of the provider’s own secrets depends almost entirely on the records the provider gives it, and on whether anyone has written rules to watch them. A buyer that has never asked what its logs would show during a token forgery has, in effect, accepted the provider’s detection as its own.

How agencies buy cloud services today

Culture slips through the net because of how a federal agency approves a cloud service. Most go through FedRAMP, the Federal Risk and Authorization Management Program. FedRAMP sets a common list of security controls, such as how access is managed, how data is encrypted and how incidents are reported. Independent assessors check a provider against that list, and the results are collected in an authorization package: a large file of documents describing the system and how it is protected.

An individual agency then reviews the package and decides whether to use the service. That decision is made by an authorizing official, a named senior person who accepts the remaining risk on the agency’s behalf. After that, the provider is monitored on an ongoing basis, mostly through reports it submits about vulnerabilities and changes.

This system has real strengths. It saves every agency from assessing the same provider from scratch, and it sets a consistent floor. But it is built to answer one question: are the required controls in place? It is much less suited to a different question: when this provider faces a hard trade-off between security and something else, which way does it lean, and does that lean change over years?

An assessment shows that controls were in place on the day it was done, which is useful. It cannot show whether staff cut corners during a busy stretch six months later. For that, a buyer needs different signals, gathered over time.

The contract and license terms add another layer. They set price, service levels and which features the agency gets. In practice, those documents are often negotiated by procurement teams focused on cost and scope, while the security review happens separately. The gap between the two is exactly where things like logging tiers and incident duties fall through.

What continuous monitoring sees, and what it misses

After authorization, FedRAMP relies on continuous monitoring. Providers submit regular vulnerability scan results and a plan of action and milestones, the running list of known weaknesses and when they will be fixed. An independent assessor repeats part of the assessment each year. Significant changes to the system require review before they go live.

That process is good at finding unpatched servers and overdue fixes. It is weaker on decisions that never appear as a finding. When Microsoft stopped rotating consumer keys, no vulnerability scan flagged it, because nothing was misconfigured in the usual sense. A practice had simply lapsed. The FedRAMP Authorization Act of 2022 wrote the program into law and told agencies to presume that FedRAMP authorizations are adequate. That presumption saves effort. It also means few agencies dig past the package.

How banks, hospitals and states buy the same service

Other sectors buy the same platforms under different rules. Banks follow interagency guidance on third-party relationships, issued by the Federal Reserve, the FDIC and the OCC in June 2023. It expects due diligence before signing, contract terms that support oversight, and ongoing monitoring scaled to how critical the service is. Those agencies can also examine certain bank service providers directly under the Bank Service Company Act.

Credit unions are in a weaker position. Their regulator, the National Credit Union Administration, lacks comparable authority to examine third-party vendors, a gap it has long asked Congress to close. A credit union’s own contract and due diligence are most of what it has.

Health systems rely on business associate agreements under HIPAA, which bind a cloud provider that handles protected health information to safeguard it and report breaches. No federal health agency certifies cloud services the way FedRAMP does, so hospitals lean on independent attestation reports such as SOC 2. State and local governments vary widely. Some accept FedRAMP authorizations. Others use StateRAMP, a nonprofit program modeled on FedRAMP, or their own reviews.

In every case the documents describe controls at a point in time. None of the frameworks asks directly how a provider behaves under pressure over years. The evidence this article describes fills that gap in each of them.

Secrets: what happens to the crown jewels over years

The stolen key dated from 2016. According to the board, it should have been retired in 2021, but Microsoft had stopped rotating consumer keys entirely that year, after a major cloud outage linked to its manual rotation process. A key that should have expired was still trusted. Flaws in token validation then let a consumer key sign tokens that enterprise email accepted.

No control assessment at a single point in time is designed to catch that kind of drift. Key management policies existed. The failure was that a known risk was deferred, year after year, while other work took priority. That is what a culture problem looks like from the outside: a gap between policy and practice that widens over time.

Why the rotation stopped matters. A manual process had caused an outage, and an outage is visible, costly and embarrassing. A stale key is invisible until someone abuses it. Faced with that trade-off, it is very human to stop doing the thing that caused the visible problem. A healthy security culture is one that notices the invisible risk and fixes the process, for example by automating it, rather than simply stopping.

A buyer can ask for evidence of practice rather than policy. Useful questions include when signing keys for the services the agency uses were last rotated, whether rotation is automated, and who approves exceptions. Others ask how the provider would know if a key were used outside its intended scope. Agencies can also ask for any open findings on key management from the provider’s own audits. The answers matter less than whether the provider can give them quickly and specifically.

Two further questions get at how much damage one leaked secret could do. The first is how long a key stays valid, since a key that lives for years exposes every token it signed during that time. The second is how strictly keys are separated, between consumer and enterprise systems and between regions or government clouds. The 2023 intrusion turned on a key crossing a boundary it should never have crossed. A provider that can explain its boundaries, and how it tests them, has thought about the problem.

Who asks matters as well. These questions belong in the security review that supports the authorization decision, and the contracting officer should put them in writing so the answers become part of the record. Asked informally by a program office, they tend to get marketing answers. Asked as a condition of renewal, with the authorizing official’s name attached, they tend to get engineers.

Reading the answers

Strong answers have a recognizable shape. They give dates, name the mechanism, such as automated rotation with keys held in hardware security modules, and describe how exceptions are approved and tracked. They point to independent evidence, such as findings in a SOC 2 report or an annual assessment, and say how open items are being closed.

Weak answers have a shape too. They describe policy rather than practice, cite certifications without specifics, or promise to follow up and never do. A provider may legitimately decline to put some details in writing, since precise key management information is itself sensitive. In that case, the buyer can ask for a technical briefing under a nondisclosure agreement and record that it took place, with the date and the people present.

Small buyers face an obvious limit. A county or a community bank does not have the buying power of a cabinet department. It can still ask, and it can rely on others who ask. Buying through a state contract, a cooperative purchasing arrangement or a sector group pools the questions and the answers. A provider that answers a large buyer specifically has set a standard that smaller customers can cite.

Disclosure: who finds the failure, and what they say

The State Department found the intrusion, not Microsoft. Afterward, the provider’s public root-cause explanation stood for about six months after Microsoft knew it lacked evidence for it. The board treated both facts as part of the cultural failure.

A root-cause explanation is the account of why something happened, as well as what happened. Organizations rely on it to decide what to do next. If the explanation is “the key leaked through a crash dump,” the natural response is to check how your own crash data is handled and move on. If the honest answer is “we do not yet know,” the response is very different: more caution, wider searches, and perhaps more aggressive steps to change credentials.

For agencies, the second fact may matter more. Agency leaders brief inspectors general, oversight committees and their own boards from the provider’s account. If that account is wrong, the agency’s own record is wrong. Its risk decisions, such as whether to rotate credentials, which logs to search and whether to notify affected people, rest on facts it cannot independently check.

The same is true for a company. Take the general counsel of a regional bank briefing the board’s risk committee after a provider incident. Everything she says about cause, scope and remedy comes from the provider. If the provider later revises its account without fanfare, her briefing, and possibly the bank’s notice to its regulator, rested on something untrue. Nobody at the bank did anything wrong, yet the bank’s record is now inaccurate.

Contracts can address this directly. They can require incident notification within defined hours, root-cause reports to a defined standard, and a duty to correct earlier statements within a set period once facts change. They can also give the agency a right to a technical briefing with the provider’s investigators as well as its account team. FedRAMP’s incident reporting runs through its own channels. An agency-level clause ensures the agency hears directly, in time to act.

Timelines a contract can fix

Sector rules already set some clocks, and contracts can build on them. Since 2022, US banks have had to notify their federal regulator within 36 hours of a significant computer-security incident. Their service providers must notify affected bank customers as soon as possible when an incident disrupts service for four hours or more. Defense contractors report cyber incidents within 72 hours under defense acquisition rules. Under HIPAA, a business associate must tell the covered entity of a breach without unreasonable delay and within 60 days at most. Public companies must disclose material cyber incidents within four business days of deciding they are material.

No clock guarantees that the first account is right. A contract can add the missing piece: a duty to update. It can require written updates at set intervals until the investigation closes, and a specific correction notice when a previously stated cause, scope or remedy turns out to be wrong.

The trade-off in demanding answers early

Pressing for a fast root cause has a cost. A provider pushed to name a cause early may name the most plausible one rather than a confirmed one, which is roughly what happened with the crash dump account. A better clause asks for early facts with stated confidence, and separates “confirmed,” “likely” and “unknown.” That lets a buyer act on what is known while treating the rest with caution. It also gives the provider a way to be honest about uncertainty without appearing evasive.

What a direct briefing adds

A technical briefing from the provider’s investigators gives a buyer things a public post does not. It can cover indicators specific to the buyer’s tenant, the timeline of activity in its environment and which of its accounts were touched. Security staff can ask follow-up questions and test the account against their own logs. The briefing also creates a record, with names and dates, that the buyer can cite when it reports to its own regulator or oversight body. Clauses guaranteeing such briefings are easiest to win before an incident, at signing or renewal, and nearly impossible to negotiate during one.

Provider disclosures to investors are another source. Since December 2023, public companies have had to disclose material cyber incidents under an SEC rule, and Microsoft filed such a disclosure about the January 2024 intrusion into its corporate email. Those filings are written for investors. They say little about what happened in any one customer’s environment, so they set a floor for what a buyer learns rather than replacing a briefing.

Defaults: what the provider ships to everyone

The State Department saw the intrusion because it had a premium license that included detailed mailbox audit logs. An audit log is a running record of activity: who signed in, from where, and which mailboxes they opened. Agencies without that license would have had a harder time. Microsoft announced broader logging for standard customers in July 2023, after the intrusion was disclosed. The board recommended a minimum standard for default audit logging across cloud providers.

Defaults are the most visible signal of how a provider weighs security against revenue and convenience. Logging sold as an upgrade, multifactor authentication that is optional at setup, and administrative features enabled by default all reveal those priorities. Multifactor authentication, for readers who have not met the term, is the second check after a password, such as a code sent to your phone. When it is optional, many customers never switch it on.

Defaults are also negotiable. An agency’s security baseline can list the logs, retention periods and secure settings it requires, and price the offer on that basis rather than on the base tier. Retention period simply means how long the records are kept. Records erased after a week are of little use when an intrusion is discovered months later.

There is a market dimension too. Federal agencies together are among the largest cloud buyers anywhere. When several large agencies ask for the same defaults at renewal, a provider has reason to make them standard for everyone. The 2023 logging change, which followed a federal customer’s discovery of the intrusion, suggests that pressure from large buyers can move a default. Coordinating those asks through shared contract language is one of the few ways agencies can change a provider’s behavior without regulation.

Defaults beyond logging

Logging was the default the board singled out, but others carry similar weight. Multifactor authentication for administrators, blocking legacy sign-in methods that cannot use it, limiting who can create new applications with access to mail, and restricting external sharing all affect how far an intruder can go. Each can be switched on by the customer, and each is often left off when a service is first configured. A buyer can list these settings in its baseline and ask the provider to confirm which are on by default and which require action.

The price of seeing

Logging has costs beyond the license. Logs that are collected must be stored, searched and reviewed, usually by sending them to a separate security monitoring system that charges by volume. Longer retention multiplies that cost. A small agency or credit union may reasonably decide it cannot afford to keep every log for a year.

The sensible response is to choose deliberately. Identify the few logs that would reveal the most damaging attacks, such as sign-ins, mailbox access and administrative changes. Keep them long enough to cover the typical time between intrusion and discovery. Accept shorter retention for the rest. The failure in 2023 was less that customers chose cheaper tiers than that many did not know what the cheaper tier left out.

Some sectors have a regulatory reason to care. The HIPAA Security Rule requires covered entities and business associates to have mechanisms that record and examine activity in systems holding electronic protected health information. A health system that relies on a cloud mail service for clinical communication should know whether its license tier gives it the records it would need to meet that standard during an investigation. Banks face similar expectations from examiners about audit trails for critical systems.

The work moves; the accountability stays

The report’s hardest message is that moving to the cloud moves work while accountability stays where it was. An agency or company that hands its email to a provider still answers to its regulators, its customers and the public when that email is read by someone else. What it gives up is direct control over the safeguards.

That shift has a cost side and a risk side. On cost, the premium tier that included detailed logs was a pricing decision. Organizations that chose the cheaper tier saved money and, without realizing it, gave up much of their ability to see an attack. On risk, a single provider failure becomes everyone’s incident at once, with the same pressure on every customer to explain, notify and remediate.

Reputation follows the record. Boards and oversight bodies do not distinguish much between “our provider failed” and “we failed.” The organizations that come through such events best are the ones that can show they asked the right questions before the incident and acted quickly on what they learned.

The three kinds of evidence should be read together. A provider that answers key management questions specifically, corrects its statements promptly and ships strong defaults is showing the culture the board found missing. One that cannot do so has told the buyer something no authorization package will.

Concentration risk

Many agencies, banks and hospitals use the same few providers for email, identity and collaboration. When one of those providers fails, the effect is correlated: thousands of customers face the same problem at once and compete for the same help. A single customer cannot change that structure.

Spreading email across several providers is rarely practical. Identity, mail and documents are tightly linked, and running two systems doubles the work of securing them. The more realistic answers are evidence, exit planning and response planning. Evidence means knowing how the provider behaves. Exit planning means knowing what it would take to move if trust collapsed. Response planning means knowing how to run critical communications if the main service were unavailable or untrustworthy for a week.

The strongest objection

A fair critic would say that none of this changes a hyperscale provider’s behavior. Its practices are set for millions of customers, and one agency’s questions will be answered by a sales team. FedRAMP and the provider’s own audits exist precisely so that each customer does not have to ask.

Part of that is right. One buyer rarely moves a provider. But the purpose of asking is partly to inform the buyer’s own decisions: which tier to buy, which logs to collect, how much to rely on the provider’s account during an incident. Those decisions are within the buyer’s control whatever the provider does. And when many buyers ask the same questions, the 2023 logging change shows that providers do respond.

Outside parties increasingly ask the same things. Cyber insurers routinely ask applicants about multifactor authentication, logging and backups before setting terms. Examiners and auditors ask how an organization oversees its critical providers. A buyer that has already gathered evidence about its cloud provider’s secrets, disclosure and defaults can answer those questions from its own file instead of from the provider’s marketing.

Treating a renewal as a security event

A well-run cloud renewal is a security event as well as a procurement one. The security team, the contracting officer and the business owner sit together, agree the questions in advance and require written answers. The baseline of logs and settings is specified before prices are compared, so that offers are judged on the same footing. Incident terms cover notification, root cause, correction and access to the provider’s investigators.

The failures are familiar. One is buying the base tier to hit a budget and discovering after an incident that the evidence needed to investigate was never collected. Another is accepting a provider’s certification as the end of the conversation, when certifications describe controls at a point in time and say little about how a provider behaves over years. A third is letting each department negotiate alone, so that no buyer is large enough to move a default. A fourth is relying on the provider’s public statements during an incident instead of insisting on a direct technical briefing.

Suppose a state revenue agency is renewing its cloud email contract. In the old approach, procurement compares three price quotes for the standard tier and picks the lowest. In the better approach, the security lead first writes down the logs the agency needs, how long it must keep them and which settings must be on from day one. Each provider prices that baseline. The contract adds a notification window, a duty to correct earlier statements and a right to speak to the provider’s investigators. The written answers about key management go into the authorization file. The cost may be somewhat higher. The agency now knows what it is buying.

Who owns each piece

The work divides cleanly. The chief information security officer writes the questions and the baseline. The contracting officer, or procurement lead in a company, puts them in the solicitation and the contract. The authorizing official, or the executive who owns vendor risk, accepts the answers or records them as findings. Legal counsel reviews incident and correction clauses. The business owner decides whether the extra cost is justified.

A few measures show whether the process is working. They include the share of critical cloud contracts with incident correction clauses and the retention period actually achieved for key logs. Others are the time the provider took to answer written security questions, and the number of open findings carried from one renewal to the next. A board or agency head can review those once a year in a single page.

Smaller organizations often buy through someone else’s contract, such as a state master agreement or a federal schedule. In that case the questions belong in the master agreement, and the smaller buyer’s job is to confirm that the terms it needs are there before it signs on.

Federal agencies often license their productivity suites through enterprise agreements or government-wide vehicles rather than separate competitions. That concentrates negotiating power in a few contracts. It also means a gap in one agreement, such as a missing correction clause, repeats across every agency that relies on it. The office that negotiates the vehicle carries an unusual share of responsibility for the security terms many agencies end up with.

What to settle before the next cloud renewal

1. Do we know which logs we receive today, how long we keep them, and whether they would have shown an intrusion like this one?
2. Are we on a license tier that gives us the records we would need to investigate, and if not, what would it cost to change?
3. At our last renewal, did we ask in writing how the provider manages and rotates its signing keys? What did they say, and how quickly?
4. Does our contract require the provider to correct an earlier incident explanation once the facts change, and to brief our technical staff directly?
5. If our provider told us tomorrow that it did not yet know how an attacker got in, what would we do differently from what we would do if it named a cause?

The questions divide naturally among owners. The first two belong to the security team, which should be able to answer them from its own configuration and license records. The third and fourth belong to procurement and legal, working from the contract file. The last is an exercise question, best answered in a tabletop session with the communications and legal staff who would face it for real. An organization that can answer all five in writing, before its next renewal, has turned a review board’s findings about one provider into evidence about its own position.

With hindsight

Microsoft responded quickly in public. In May 2024 it expanded its Secure Future Initiative, and its chief executive said security would be prioritized above other features. The company also said it would tie part of senior leadership compensation to security progress. Its president testified before the House Homeland Security Committee in June 2024 and accepted responsibility for the failures the board described. Whether those commitments changed practice is something buyers have had to judge from evidence of the kind described here.

That last point deserves weight. Public commitments are welcome, and accepting responsibility in front of Congress is no small thing. But a buyer cannot verify a speech. What a buyer can verify is whether keys are rotated, whether logs come as standard, and whether incident explanations are corrected promptly. The three tests in this article remain the practical way to see whether a culture has actually changed.

Disclosure was tested again almost at once. In April 2024, CISA issued an emergency directive about the Russian intrusion into Microsoft’s corporate email. The intruders had taken emails exchanged between Microsoft and federal agencies, and the directive told affected agencies to analyze those emails and reset any credentials they exposed. Agencies were acting, once more, on information that originated with the provider.

Defaults moved, partly through government pressure. In December 2024, CISA issued a binding operational directive requiring federal civilian agencies to adopt secure configuration baselines for their cloud services, starting with Microsoft 365. That shifted secure settings from a recommendation to an obligation, at least for those agencies. It also confirmed the article’s view that defaults are where much of the practical risk lies.

FedRAMP changed too, though in a different direction from the board’s recommendation. In July 2024, OMB issued a memo modernizing the program, and in 2025 FedRAMP launched an effort called 20x aimed at faster, more automated authorizations. Their emphasis was speed and continuous evidence rather than the special post-incident reviews the board had proposed.

Microsoft’s later progress reports said it had moved the signing keys for its consumer and enterprise identity systems into hardened, hardware-protected infrastructure with automatic rotation. Those are the right changes to claim. They are also the kind of claim a customer should ask to see evidence for at renewal, which is the habit the board’s report argued for.

The board itself did not last. In January 2025, DHS terminated the memberships of its advisory committees, the CSRB’s among them, and the board’s review of the Salt Typhoon telecom intrusions ended with it. That left agencies without the one federal body set up to investigate such failures independently. The questions in their own contracts, about secrets, disclosure and defaults, carry more of the weight.

The implication holds in any sector. Independent investigations of big provider failures cannot be counted on to arrive, and when they do, they arrive long after the event. The protection an organization has is mostly the protection it negotiated for itself: the logs it insisted on, the notification and correction duties in its contracts, and the habit of asking specific questions at every renewal.

Banks and hospitals were heading the same way for their own reasons. Bank regulators’ third-party guidance and the steady rise of contract-based oversight in health care both put the burden on the customer to show it understood its providers. The board’s report gave those efforts a detailed case study, even after the board was gone.

That is less glamorous than a headline report, but it is durable. It also does not depend on any one provider’s promises or any one administration’s priorities. A contract clause keeps working whether or not a review board exists.