• Thread Author
Microsoft’s cybersecurity posture is under renewed fire after U.S. Senator Ron Wyden urged the Federal Trade Commission to open a formal investigation into the company’s default security settings, arguing that Microsoft shipped “dangerous, insecure software” that materially enabled a 2024 ransomware attack on Ascension, one of America’s largest hospital networks. The senator’s letter ties an attack that disrupted surgeries and exposed millions of patient records to long-standing platform defaults — principally the continued support for the RC4 cipher and permissive Active Directory configurations — and demands regulatory action to force secure defaults and clearer guidance for customers. (wyden.senate.gov)

Hospital data breach: weak vs secure encryption depicted in a data center.Background​

The 2024 incident at Ascension has become a vivid case study in how a relatively small initial compromise can cascade into a systemic failure in healthcare operations. According to details released by Senate staff and media reporting, the chain began when a contractor clicked on a malicious search result while using Bing; that click led to malware on a corporate laptop, privilege escalation through default Windows configurations, lateral movement inside the network, and final payload delivery of ransomware that impacted thousands of machines across the system. The attack reportedly resulted in stolen personal and medical data for roughly 5.6 million patients and forced clinicians to revert to paper processes for critical care functions. (reuters.com)
Senator Wyden’s letter frames the breach as symptomatic of a company-wide security culture problem at Microsoft — one with national-security implications because Microsoft products underlie so much of U.S. government and critical infrastructure IT. He has urged the FTC to consider whether Microsoft’s defaults, disclosure practices, and product roadmaps amount to unfair or deceptive practices that warrant regulatory intervention. (wyden.senate.gov)

What Went Wrong: Kerberoasting, RC4, and Default Windows Behavior​

The attack technique — Kerberoasting in practical terms​

At the technical center of Wyden’s criticism is the technique known as Kerberoasting. In simplified terms, Kerberoasting targets service accounts in Active Directory that have Service Principal Names (SPNs) associated with them. An attacker can request Kerberos service tickets for those SPNs, extract the ticket (which has been encrypted under the service account’s password-derived key), and then mount an offline brute-force attack against that ticket to recover the account password. Weak service-account passwords or weak encryption used to protect Kerberos tickets materially reduce the time and compute required for successful recovery. (microsoft.com)

RC4 versus AES: the cryptography dispute​

Wyden’s letter highlights Microsoft’s continued support for RC4 (Rivest Cipher 4) as a default or allowable Kerberos encryption type in some product configurations. RC4 is an antiquated stream cipher with well-known biases and cryptanalytic weaknesses; security communities moved away from RC4 in TLS and other protocols years ago. Modern practice favors AES-based Kerberos encryption types that resist the same classes of offline attacks. Critics say that continued default support for RC4 essentially hands attackers a weaker target to brute-force service-account credentials used across critical environments. (arstechnica.com)
Microsoft’s own guidance has acknowledged the risk and recommended administrators manually disable RC4 for service accounts where possible, while stating an intention to disable RC4 by default in future updates to Windows client and server releases. That acknowledgement, however, has not satisfied Wyden, who argues the company has failed to move fast enough and has not proactively warned all customers of the practical threat to real-world operations. (microsoft.com)

Timeline and Competing Narratives​

  • The Ascension ransomware event took place in 2024 and impacted hospital operations and patient data at scale. Public accounts of the incident emerged over time and were central to Wyden’s recent letter. (wyden.senate.gov)
  • Microsoft published guidance explaining Kerberoasting and offering mitigation steps in October 2024, including the company’s intention to disable RC4 by default in forthcoming Windows updates. (microsoft.com)
  • In 2025, Microsoft launched the Secure Future Initiative (SFI) and published progress reports describing a company-wide security reform program and investments across engineering, tooling, and governance. Microsoft’s public messaging emphasizes “secure by design, secure by default, and secure operations.” (microsoft.com)
  • On September 10, 2025, Senator Wyden publicly called for an FTC probe, arguing that Microsoft’s defaults and uneven guidance contributed materially to the Ascension breach and that regulatory enforcement is needed to force secure-by-default behavior. (wyden.senate.gov)
There is a tension between Microsoft’s public remediation timeline and Wyden’s assessment of urgency and accountability. Microsoft says the usage of RC4 is negligible in most modern deployments and that the company will phase out the cipher in product updates, while Wyden contends a promised patch and clearer customer-facing warnings are long overdue. Both positions rest on different readings of risk, timing, and responsibility. (reuters.com)

Technical Deep Dive: Why Defaults Matter​

Defaults drive behavior. In enterprise IT, the path of least resistance for busy administrators is often to accept vendor defaults, particularly when an operating system or directory service is centrally managed. When defaults are permissive or conservative about backwards compatibility, the result is a wide population of systems that remain vulnerable until someone explicitly hardens them.
  • Active Directory has a long legacy: many domain environments contain service accounts with legacy constraints or third-party applications that were designed against older Kerberos encryption sets. As a result, administrators may leave RC4 enabled to preserve compatibility. (microsoft.com)
  • Password policies matter: Kerberoasting is feasible where service-account passwords are short, reuse common patterns, or are rarely changed. Wyden and others note that Microsoft’s guidance and default password policy settings have not historically enforced the complex, long service-account credentials needed to make Kerberoasting impractical at scale. (wyden.senate.gov)
  • Hardening is often manual: Microsoft’s guidance has emphasized auditing SPNs, enforcing AES encryption types, and rotating credentials — but these steps require active programmatic intervention from IT teams, not a simple automatic fix. That gap between vendor recommendation and customer action is what Wyden argues leaves critical services exposed. (microsoft.com)
From a security-engineering perspective, the desired posture for a vendor with Microsoft’s footprint is to ship secure defaults that protect the majority of customers by default and offer explicit, supported compatibility modes for legacy scenarios. When defaults are lax, the least secure path becomes the most common path.

Microsoft’s Response and the Secure Future Initiative​

Microsoft has acknowledged the general class of risk and has launched its Secure Future Initiative (SFI) — a multiyear, high-investment program that the company says embeds security into product design, delivery, and operations. Public SFI materials detail new engineering toolkits, governance measures, threat-modeling practices, and product changes intended to raise baseline security across Windows, Azure, and Microsoft 365. (microsoft.com)
On RC4 specifically, Microsoft’s public statements have shifted slightly across 2024–2025: the company initially documented mitigation guidance and a planned move to disable RC4 by default in future client and server updates, and later statements acknowledged the need for a phased approach, noting that RC4 traffic represents a small fraction of Kerberos usage in modern deployments. Microsoft has also pointed customers to detailed configuration steps and auditing guidance for enforcing AES. Those technical disclosures are important but — according to critics — have not translated into a companywide removal of risky defaults in all deployed products as quickly as security experts demand. (microsoft.com)

Regulatory and Accountability Dimensions​

Wyden’s call for an FTC investigation elevates the conversation from technical remediation to legal and regulatory accountability. The senator’s letter asks regulators to determine whether Microsoft’s product choices and disclosures constitute unfair or deceptive practices, and whether companies that provide foundational enterprise software should be compelled to ship secure defaults or face consequences.
This is not the first time Microsoft’s security culture has been publicly scrutinized. A U.S. Cyber Safety Review Board report into a 2023 hack that impacted government email accounts criticized Microsoft for operational and process failures that worsened the fallout from nation-state actors. That prior review has been cited by Wyden and others as evidence that internal reform at Microsoft is still a work in progress. (reuters.com)
If the FTC elects to investigate — and ultimately to take enforcement action — the consequences could reshape vendor obligations for default security settings, transparency about known vulnerabilities, and timetables for shipping security fixes. This would set precedent for how regulators treat dominant platform providers whose decisions cascade across critical infrastructure sectors.

Practical Remedies: Technical and Policy Options​

Whether spurred by regulation or market pressure, a credible remediation plan for this class of exposure would include both immediate operational steps and longer-term platform changes. Recommended actions fall into three buckets:
  • Product-level changes:
  • Disable legacy, weak encryption types (RC4) by default across all supported Windows and Active Directory builds, with clear compatibility fallback policies.
  • Ship user-friendly, mandatory hardening wizards or post-install “security baseline” prompts for enterprise deployments.
  • Provide telemetry-driven advisories to admins where legacy crypto is detected, including automated remediation options. (microsoft.com)
  • Operational controls for customers:
  • Audit and remove unnecessary SPNs and harden service-account usage.
  • Enforce long, unique service-account passwords and rotate them automatically.
  • Adopt passkeys, passwordless authentication, or managed identities where feasible to reduce reliance on long-lived service account secrets. (microsoft.com)
  • Regulatory and transparency measures:
  • Mandatory timelines for phasing out insecure defaults where vendor market power affects critical infrastructure.
  • Plain-language advisories sent directly to administrators in affected sectors (healthcare, government, utilities) when vendor-supplied defaults or vulnerabilities are likely to affect operations.
  • Disclosure requirements when vendors ship compatibility-driven defaults that increase systemic risk. (wyden.senate.gov)
These measures combine engineering fixes with governance and transparency — the kind of multi-layered approach Microsoft’s SFI claims to embody, but that critics argue must be more aggressively executed and more directly enforced for sectors that can’t tolerate downtime.

Strengths, Weaknesses, and Unverified Claims​

Notable strengths in Wyden’s case​

  • The senator’s argument is concrete: it ties a widely reported operational failure at a major hospital operator to specific, long-standing platform choices and a documented attack technique (Kerberoasting). That specificity makes the case more actionable for regulators and for technical remediators. (wyden.senate.gov)
  • The complaint leverages prior external findings — such as the Cyber Safety Review Board’s 2023 critique — to argue that Microsoft’s public reforms are necessary but not yet sufficient. (reuters.com)

Real weaknesses and caveats​

  • Attribution of causality in complex breaches is hard. While default crypto and policy settings made exploitation easier, successful attacks typically chain together many failings — user behavior, phishing or malicious content, patch levels, and local admin practices. Holding a single vendor fully accountable for every downstream operational failure risks oversimplifying incident root causes. (reuters.com)
  • Microsoft’s claim that RC4 is used only for a tiny fraction of traffic is supported by vendor telemetry; the company says it will disable RC4 by default in future updates. The practical deployment schedule and customer impact for those changes are sources of disagreement between the company and observers. This raises a timing and rollout debate rather than an absolute technical denial. (reuters.com)

Unverifiable or disputed assertions​

  • Wyden accuses Microsoft of operating a “multibillion-dollar secondary business selling cybersecurity add-on services” and likens the company to “an arsonist selling firefighting services.” While Microsoft does have a substantial security services and product portfolio, public filings and communications do not straightforwardly attribute the company’s product design decisions to profit motives in a verifiable way. That rhetorical framing is a policy judgment and should be treated as an allegation rather than an established fact. (wyden.senate.gov)
  • Whether Microsoft intentionally delayed or obscured guidance by burying it in a low-profile blog post is partly subjective. Microsoft has published technical mitigation guidance dating back to 2024 and has issued SFI progress reports in 2025; critics argue the speed and clarity were insufficient, while the company frames its actions as deliberate and coordinated. The difference is interpretive and contextual. (microsoft.com)

What Happens Next: Scenarios and Stakes​

If the FTC opens an investigation and finds Microsoft’s actions to be unfair or deceptive, the agency could require binding changes to product defaults, disclosures, and compliance timelines — outcomes that would ripple through the enterprise software market. Alternatively, regulators might issue nonbinding guidance or fines, or decline action, leaving market pressure and customer risk-management to drive change.
For healthcare providers and other critical infrastructure operators, the practical stakes are immediate: the operational impact of ransomware — delayed surgeries, degraded care, lost data — imposes direct risk to human safety and patient privacy. The Ascension case demonstrates that vendor defaults are not an abstract engineering concern but a governance issue with life-and-death consequences. (wyden.senate.gov)
From a vendor governance perspective, the episode underscores a broader question: should market dominance carry with it higher obligations to ship secure defaults and transparent, plain-English warnings when defaults materially raise systemic risk? Wyden’s letter contends yes — and his push could define the regulatory contours for that debate in the months ahead. (wyden.senate.gov)

Conclusion​

The Wyden letter crystallizes a growing tension between dominant platform providers and the public interest in resilient critical infrastructure. The Ascension ransomware case anchors the debate in a tangible, high-impact incident: millions of patients affected, clinicians forced to work offline, and a long, expensive remediation left in the wake. Whether regulators agree with Wyden’s characterization of Microsoft as negligent or whether they accept Microsoft’s stated remediation plan will determine the next chapter of accountability for software vendors whose defaults shape national cyber risk.
Technical patches, stronger defaults, and better customer-facing guidance are all achievable. The harder questions are institutional: how quickly will vendors remove risky compatibility defaults, how transparently will they communicate residual risks, and what legal standards will be applied to companies whose platforms underpin critical services? The answer will shape not only Microsoft’s product roadmap, but also the governance expectations for every vendor whose code sits at the base of modern healthcare, government, and industrial systems. (wyden.senate.gov)

Source: theregister.com Senator blasts Microsoft for 'dangerous, insecure software'
 

Back
Top