The case for a new federal technology strategy is no longer about whether Microsoft software is useful. It is about whether the United States can safely allow one vendor’s operating systems, productivity suite, identity platform, cloud services, and security tooling to become so deeply interwoven with government work that a defect in one layer can ripple across the whole enterprise.
That is the warning in the recent Daily Wire essay, “America Needs To Renegotiate Its Most Famous Software Marriage”. Its central argument is provocative but not frivolous: Washington’s relationship with Microsoft has created a concentration-of-risk problem that procurement policy can no longer treat as a mere commercial preference.
The article uses the newly reported Mythos AI framework as an alarm bell. The claim is not simply that AI will make software bugs more common; defects have always existed. The harder proposition is that increasingly capable automation may compress the time from vulnerability discovery to weaponized exploitation. In a federal environment built around shared Microsoft dependencies, that compression matters because the same foundational services may be protecting email, endpoints, identities, documents, collaboration platforms, and cloud workloads at once.
Microsoft remains indispensable to vast portions of the public sector for understandable reasons. Its products are familiar, integrated, extensively supported, and available at the scale that government agencies require. But indispensability is precisely what makes the relationship strategically fraught. A government can benefit from standardization without allowing standardization to become a single point of national failure.
The essay’s framing should not be misread as a call to purge Microsoft from federal networks. Replacing a pervasive enterprise platform overnight would be operationally reckless, expensive, and potentially less secure than the status quo. Agencies rely on Microsoft’s tools because they support real mission needs, including collaboration across organizational boundaries, endpoint management, cloud-hosted systems, and identity integration.
The stronger argument is that the federal government needs meaningful exit options. A customer with realistic alternatives can negotiate harder, limit blast radius, test resilience, and move workloads when performance, pricing, security, or geopolitical considerations demand it. A customer without those options is not merely loyal; it is structurally dependent.
That dependence is reinforced by the breadth of Microsoft’s government footprint. In May, the Department of War announced a five-year enterprise agreement valued at approximately $9.7 billion, covering Microsoft 365, cloud subscriptions, and on-premises licensing. The department described the agreement as foundational to secure communications, collaboration, cloud services, and operational continuity from headquarters to disconnected tactical environments. The department’s own announcement illustrates both sides of the debate: a unified commercial stack can simplify procurement and interoperability, but it also increases the strategic importance of one supplier.
This is the essential distinction policymakers must preserve:
Microsoft Entra ID, formerly Azure Active Directory, is central to authentication and authorization in many Microsoft 365 and Azure deployments. It can connect users, devices, applications, cloud subscriptions, collaboration services, and administrative roles. That integration is a major operational advantage. It is also why an identity compromise can have consequences far beyond an individual mailbox or workstation.
The 2023 Storm-0558 intrusion remains the clearest demonstration of the stakes. China-linked attackers accessed cloud email accounts belonging to senior U.S. officials after using forged authentication tokens. The Cyber Safety Review Board’s review concluded that the incident was preventable and found a “cascade of avoidable errors” behind the compromise. CISA’s publication of the board’s review documented the importance of the incident not simply as an email breach, but as a cloud identity and trust failure.
The federal response showed how seriously Washington viewed the broader implications. After a separate Microsoft-related campaign involving Midnight Blizzard, CISA issued Emergency Directive 24-02, requiring civilian executive-branch agencies to assess potentially exposed data, reset credentials, and take additional actions around privileged Azure accounts. CISA’s directive announcement made clear that compromise of a major cloud provider’s corporate environment could translate into direct government remediation obligations.
That history does not prove that Microsoft is uniquely incapable of securing cloud identity. Every large technology supplier has experienced incidents, and attackers naturally prioritize platforms with broad adoption. But it does prove a more modest—and more important—point: when a provider sits at the center of government identity, its failures become government-wide risk-management events.
Consider the layers that may be connected in a Microsoft-heavy deployment:
That is not an argument against integrated security platforms. It is an argument for independent visibility, segmented administrative control, and the ability to operate important workloads through more than one technology path.
The principle is sound even if licensing details evolve over time. Security telemetry is not a decorative management feature. In the aftermath of a cloud incident, audit records can reveal sign-ins, mailbox access, administrative changes, application activity, and data movement. Without sufficiently complete logs, an agency may not know what an intruder accessed, how long access persisted, or whether remediation was effective.
Microsoft’s current documentation confirms that audit retention differs by subscription. Organizations with qualifying E5 licenses or specific add-ons receive one-year default retention for certain Entra ID, Exchange, and SharePoint audit records, while other licensing arrangements receive a shorter default retention period. Microsoft’s audit-log documentation also notes that record availability and searchable retention vary by service and license.
This model is commercially familiar. Advanced retention, eDiscovery, data governance, and security analytics are often sold in tiers across the software industry. But federal procurement should distinguish between optional administrative enhancements and the minimum evidence needed to defend public systems.
If an agency cannot determine which accounts were accessed during a serious intrusion without buying a top-tier bundle, the procurement system has confused product segmentation with national-security design.
Federal agencies rarely choose a cloud provider in a clean-room exercise. They inherit legacy applications, endpoint management systems, directory services, support agreements, staff skills, compliance approvals, data structures, and software licenses. A decision that once appeared to be a cost-saving standardization effort can become a long-term constraint once it is expensive to run familiar software anywhere except the original vendor’s cloud.
The Government Accountability Office has repeatedly found that restrictive licensing practices can affect agencies’ cloud choices and costs. In its review of selected civilian agencies, GAO reported examples of vendors requiring agencies to repurchase licenses for cloud use, charging additional fees to run software on third-party infrastructure, and using contract terms that encouraged vendor lock-in. GAO’s cloud-computing report also found that agencies had not fully established guidance for identifying and mitigating such practices.
The problem is not limited to Microsoft, and it should not be presented as if every restrictive practice is illegal or automatically malicious. Software licensing is complex because cloud services blur traditional distinctions among a product, a hosted service, support, storage, compute, and security operations. Even GAO has observed that federal acquisition rules do not always fit modern cloud purchasing neatly. Its more recent procurement analysis notes that agencies and acquisition officials struggle to map rapidly changing cloud offerings onto legacy procurement definitions.
Still, the practical effect can be damaging. When an agency pays more to use already licensed software on another cloud, or must repurchase tools to leave an incumbent environment, the “choice” of cloud provider becomes increasingly theoretical.
That assessment should include:
This is not merely an accounting concern. If an agency cannot afford to move a workload after a security failure, the vendor’s remediation timetable effectively becomes the agency’s only available plan.
That issue was not hypothetical. In 2025, the Pentagon said it had halted the program after learning that Chinese nationals had been servicing Defense Department cloud environments under supervision by U.S.-based personnel. The department characterized the arrangement as an unacceptable risk, required a third-party audit of the program, and directed vendors to identify and end Chinese involvement with Department of Defense cloud systems. The Department of War’s account of the decision is unambiguous about the government’s concern.
This episode requires careful analysis. Nationality alone is not a substitute for a security assessment, and secure technology programs depend on clear controls, reviewed code, least-privilege access, logging, contractual accountability, and vetted personnel. But the question becomes more acute when work concerns sensitive government infrastructure and involves personnel located in a strategic competitor’s jurisdiction.
The digital-escort controversy illustrates a broader procurement principle: security assurances must be technically auditable, not merely contractually asserted. A cleared intermediary cannot compensate for inadequate technical understanding of the work being supervised. If an escort is unable to assess code changes, support actions, permissions, or data flows, the oversight model may provide paperwork without providing assurance.
Running a few isolated workloads on multiple providers is not the same as achieving operational resilience. Likewise, duplicating every application across several clouds may create cost, latency, skills, configuration, and governance problems that outweigh the benefit. Different systems have different recovery needs, data sensitivities, and mission requirements.
The better goal is deliberate diversity. Agencies should determine which capabilities are so critical that they need an independent alternative and which can remain standardized without creating unacceptable systemic risk.
The Joint Warfighting Cloud Capability provides an instructive model. The Department of Defense awarded JWCC contracts to Amazon Web Services, Google, Microsoft, and Oracle, creating a multivendor vehicle for commercial cloud services across unclassified, secret, and top-secret environments. The Defense Department’s JWCC announcement explicitly tied the arrangement to resilience, readiness, and access to cloud capabilities across the department.
JWCC is not a complete answer. A multivendor contract vehicle does not automatically make applications portable, eliminate identity dependencies, or ensure that agencies are actually able to shift workloads during a crisis. But it does establish an important procurement posture: government should not have to choose between a single mega-vendor and ad hoc, ungoverned technology fragmentation.
The Defense Department’s recent enterprise agreement reflects the government’s continuing belief that Microsoft’s integrated services can support mission operations at scale. The department described the deal as a way to reduce fragmented procurement, create standardized configurations, and improve interoperability across military services and agencies.
Those benefits are genuine. Fragmentation can create its own security failures: inconsistent patching, unmanaged identities, incompatible encryption policies, shadow IT, unclear accountability, and inadequate support. A federal government with hundreds of incompatible tools and no common operational standards would not be more resilient simply because it had more logos in its data centers.
The policy objective, therefore, should be neither monopoly by default nor diversity for its own sake. It should be managed concentration: use shared platforms where they deliver genuine operational value, but limit the number of functions that depend on one vendor’s control plane and preserve credible alternatives for the most critical services.
Microsoft can be part of that solution. In fact, a supplier confident in its security, interoperability, and pricing should be able to compete effectively in a federal market that rewards portability rather than penalizes it.
Congress does not need to order agencies to abandon Windows, Outlook, Azure, or Entra ID. It should insist that agencies know the cost of moving, can retain independent security evidence, and can sustain vital operations if one supplier suffers a major compromise or service failure.
A credible federal technology resilience agenda would require:
The federal government does not need a divorce from Microsoft. It needs a better contract—one that preserves the benefits of a powerful technology partner while ensuring that no single supplier’s mistake, breach, licensing decision, or support model can place too much of the government at risk all at once.
That is the warning in the recent Daily Wire essay, “America Needs To Renegotiate Its Most Famous Software Marriage”. Its central argument is provocative but not frivolous: Washington’s relationship with Microsoft has created a concentration-of-risk problem that procurement policy can no longer treat as a mere commercial preference.
The article uses the newly reported Mythos AI framework as an alarm bell. The claim is not simply that AI will make software bugs more common; defects have always existed. The harder proposition is that increasingly capable automation may compress the time from vulnerability discovery to weaponized exploitation. In a federal environment built around shared Microsoft dependencies, that compression matters because the same foundational services may be protecting email, endpoints, identities, documents, collaboration platforms, and cloud workloads at once.
Microsoft remains indispensable to vast portions of the public sector for understandable reasons. Its products are familiar, integrated, extensively supported, and available at the scale that government agencies require. But indispensability is precisely what makes the relationship strategically fraught. A government can benefit from standardization without allowing standardization to become a single point of national failure.
The Real Issue Is Concentration, Not Microsoft’s Existence
The essay’s framing should not be misread as a call to purge Microsoft from federal networks. Replacing a pervasive enterprise platform overnight would be operationally reckless, expensive, and potentially less secure than the status quo. Agencies rely on Microsoft’s tools because they support real mission needs, including collaboration across organizational boundaries, endpoint management, cloud-hosted systems, and identity integration.The stronger argument is that the federal government needs meaningful exit options. A customer with realistic alternatives can negotiate harder, limit blast radius, test resilience, and move workloads when performance, pricing, security, or geopolitical considerations demand it. A customer without those options is not merely loyal; it is structurally dependent.
That dependence is reinforced by the breadth of Microsoft’s government footprint. In May, the Department of War announced a five-year enterprise agreement valued at approximately $9.7 billion, covering Microsoft 365, cloud subscriptions, and on-premises licensing. The department described the agreement as foundational to secure communications, collaboration, cloud services, and operational continuity from headquarters to disconnected tactical environments. The department’s own announcement illustrates both sides of the debate: a unified commercial stack can simplify procurement and interoperability, but it also increases the strategic importance of one supplier.
This is the essential distinction policymakers must preserve:
- Standardization reduces complexity.
- Monoculture concentrates exposure.
- Interoperability gives agencies choice.
- Lock-in converts a commercial relationship into a security dependency.
Why Identity Is the Most Dangerous Layer to Centralize
Of all the Microsoft components used by government, identity deserves the closest scrutiny. Operating systems can be patched. Applications can be isolated. Email can be segmented. But identity systems determine who is trusted across everything else.Microsoft Entra ID, formerly Azure Active Directory, is central to authentication and authorization in many Microsoft 365 and Azure deployments. It can connect users, devices, applications, cloud subscriptions, collaboration services, and administrative roles. That integration is a major operational advantage. It is also why an identity compromise can have consequences far beyond an individual mailbox or workstation.
The 2023 Storm-0558 intrusion remains the clearest demonstration of the stakes. China-linked attackers accessed cloud email accounts belonging to senior U.S. officials after using forged authentication tokens. The Cyber Safety Review Board’s review concluded that the incident was preventable and found a “cascade of avoidable errors” behind the compromise. CISA’s publication of the board’s review documented the importance of the incident not simply as an email breach, but as a cloud identity and trust failure.
The federal response showed how seriously Washington viewed the broader implications. After a separate Microsoft-related campaign involving Midnight Blizzard, CISA issued Emergency Directive 24-02, requiring civilian executive-branch agencies to assess potentially exposed data, reset credentials, and take additional actions around privileged Azure accounts. CISA’s directive announcement made clear that compromise of a major cloud provider’s corporate environment could translate into direct government remediation obligations.
That history does not prove that Microsoft is uniquely incapable of securing cloud identity. Every large technology supplier has experienced incidents, and attackers naturally prioritize platforms with broad adoption. But it does prove a more modest—and more important—point: when a provider sits at the center of government identity, its failures become government-wide risk-management events.
The blast-radius problem
A single vulnerability does not always produce a catastrophic breach. The damage depends on segmentation, privileges, logging, detection, access controls, and response speed. Yet centralizing many critical functions under one vendor increases the odds that a flaw, misconfiguration, compromised administrative account, or supply-chain failure will affect multiple systems simultaneously.Consider the layers that may be connected in a Microsoft-heavy deployment:
- Windows endpoints and servers;
- Exchange Online and Outlook mailboxes;
- Teams collaboration data;
- SharePoint and OneDrive repositories;
- Entra ID authentication;
- Azure-hosted applications;
- Defender security telemetry;
- Intune device management;
- Microsoft Purview governance and compliance tooling.
That is not an argument against integrated security platforms. It is an argument for independent visibility, segmented administrative control, and the ability to operate important workloads through more than one technology path.
Audit Logs Should Not Be a Luxury Security Feature
One of the most compelling criticisms in the supplied essay concerns audit logging. The article argues that the State Department’s visibility during the Storm-0558 incident depended on a higher Microsoft license tier, raising an uncomfortable question: should foundational forensic evidence be packaged as a premium product?The principle is sound even if licensing details evolve over time. Security telemetry is not a decorative management feature. In the aftermath of a cloud incident, audit records can reveal sign-ins, mailbox access, administrative changes, application activity, and data movement. Without sufficiently complete logs, an agency may not know what an intruder accessed, how long access persisted, or whether remediation was effective.
Microsoft’s current documentation confirms that audit retention differs by subscription. Organizations with qualifying E5 licenses or specific add-ons receive one-year default retention for certain Entra ID, Exchange, and SharePoint audit records, while other licensing arrangements receive a shorter default retention period. Microsoft’s audit-log documentation also notes that record availability and searchable retention vary by service and license.
This model is commercially familiar. Advanced retention, eDiscovery, data governance, and security analytics are often sold in tiers across the software industry. But federal procurement should distinguish between optional administrative enhancements and the minimum evidence needed to defend public systems.
A federal security baseline should include
- Sufficient default audit retention for identity, email, collaboration, endpoint, and cloud-control-plane activity.
- Exportable logs that can be stored independently of the provider’s primary console.
- Machine-readable access through documented APIs, without punitive licensing barriers.
- Cross-platform monitoring so a single vendor’s security portal is not the sole source of truth.
- Regular forensic exercises that test whether investigators can reconstruct activity after a suspected compromise.
If an agency cannot determine which accounts were accessed during a serious intrusion without buying a top-tier bundle, the procurement system has confused product segmentation with national-security design.
Licensing Can Quietly Turn Technology Into a Strategic Dependency
The Daily Wire essay’s strongest policy point is not its criticism of a particular Microsoft product. It is its focus on the incentives embedded in enterprise licensing.Federal agencies rarely choose a cloud provider in a clean-room exercise. They inherit legacy applications, endpoint management systems, directory services, support agreements, staff skills, compliance approvals, data structures, and software licenses. A decision that once appeared to be a cost-saving standardization effort can become a long-term constraint once it is expensive to run familiar software anywhere except the original vendor’s cloud.
The Government Accountability Office has repeatedly found that restrictive licensing practices can affect agencies’ cloud choices and costs. In its review of selected civilian agencies, GAO reported examples of vendors requiring agencies to repurchase licenses for cloud use, charging additional fees to run software on third-party infrastructure, and using contract terms that encouraged vendor lock-in. GAO’s cloud-computing report also found that agencies had not fully established guidance for identifying and mitigating such practices.
The problem is not limited to Microsoft, and it should not be presented as if every restrictive practice is illegal or automatically malicious. Software licensing is complex because cloud services blur traditional distinctions among a product, a hosted service, support, storage, compute, and security operations. Even GAO has observed that federal acquisition rules do not always fit modern cloud purchasing neatly. Its more recent procurement analysis notes that agencies and acquisition officials struggle to map rapidly changing cloud offerings onto legacy procurement definitions.
Still, the practical effect can be damaging. When an agency pays more to use already licensed software on another cloud, or must repurchase tools to leave an incumbent environment, the “choice” of cloud provider becomes increasingly theoretical.
Procurement must measure the cost of leaving
Federal contracts commonly focus on purchase price, discounts, security certifications, service-level agreements, and implementation schedules. Those are important, but they are incomplete. Agencies should also calculate an exit cost before entering a major enterprise agreement.That assessment should include:
- The cost of exporting data in usable formats;
- Application rehosting or refactoring expenses;
- Identity migration complexity;
- Retraining for administrators and end users;
- Replacement security controls;
- Contractual penalties or conversion fees;
- The portability of logs, encryption keys, backups, and configuration data;
- The viability of alternative providers at the necessary security classification.
This is not merely an accounting concern. If an agency cannot afford to move a workload after a security failure, the vendor’s remediation timetable effectively becomes the agency’s only available plan.
The China Support Controversy Shows Why Supply-Chain Assurance Matters
The essay also highlights a far more sensitive concern: Microsoft’s past use of China-based engineers to support Department of Defense cloud systems under a “digital escort” arrangement.That issue was not hypothetical. In 2025, the Pentagon said it had halted the program after learning that Chinese nationals had been servicing Defense Department cloud environments under supervision by U.S.-based personnel. The department characterized the arrangement as an unacceptable risk, required a third-party audit of the program, and directed vendors to identify and end Chinese involvement with Department of Defense cloud systems. The Department of War’s account of the decision is unambiguous about the government’s concern.
This episode requires careful analysis. Nationality alone is not a substitute for a security assessment, and secure technology programs depend on clear controls, reviewed code, least-privilege access, logging, contractual accountability, and vetted personnel. But the question becomes more acute when work concerns sensitive government infrastructure and involves personnel located in a strategic competitor’s jurisdiction.
The digital-escort controversy illustrates a broader procurement principle: security assurances must be technically auditable, not merely contractually asserted. A cleared intermediary cannot compensate for inadequate technical understanding of the work being supervised. If an escort is unable to assess code changes, support actions, permissions, or data flows, the oversight model may provide paperwork without providing assurance.
What agencies should demand from cloud suppliers
For high-impact and national-security workloads, federal contracts should require more than broad statements about trusted personnel and secure delivery. They should require:- Detailed geographic and personnel-access disclosures;
- Clear identification of subcontractors and support locations;
- Continuous logging of privileged support activity;
- Government-accessible records of code changes and emergency interventions;
- Independent verification of support-boundary controls;
- Rights to audit high-risk supply-chain processes;
- Immediate notification when staffing, ownership, or support geography changes;
- Defined remedies for noncompliance.
Multi-Cloud Is Useful, but It Is Not a Magic Word
The remedy proposed in the essay—more multicloud procurement—is directionally correct. But multi-cloud can become a slogan if policymakers do not define what it is supposed to accomplish.Running a few isolated workloads on multiple providers is not the same as achieving operational resilience. Likewise, duplicating every application across several clouds may create cost, latency, skills, configuration, and governance problems that outweigh the benefit. Different systems have different recovery needs, data sensitivities, and mission requirements.
The better goal is deliberate diversity. Agencies should determine which capabilities are so critical that they need an independent alternative and which can remain standardized without creating unacceptable systemic risk.
The Joint Warfighting Cloud Capability provides an instructive model. The Department of Defense awarded JWCC contracts to Amazon Web Services, Google, Microsoft, and Oracle, creating a multivendor vehicle for commercial cloud services across unclassified, secret, and top-secret environments. The Defense Department’s JWCC announcement explicitly tied the arrangement to resilience, readiness, and access to cloud capabilities across the department.
JWCC is not a complete answer. A multivendor contract vehicle does not automatically make applications portable, eliminate identity dependencies, or ensure that agencies are actually able to shift workloads during a crisis. But it does establish an important procurement posture: government should not have to choose between a single mega-vendor and ad hoc, ungoverned technology fragmentation.
Effective diversification requires architecture, not just contracts
A federal multicloud strategy should include:- Portable application design. New systems should avoid unnecessary dependence on proprietary services when comparable open standards or portable interfaces exist.
- Federated identity. Agencies should reduce scenarios where one identity provider can become the sole authentication route for every critical system.
- Independent backups. Backups must be isolated from the same credentials, administration plane, and provider region that could be compromised in an incident.
- Cross-cloud recovery plans. Agencies should test whether priority workloads can be restored elsewhere, not merely claim that they could be.
- Open data formats. Data should be exportable without a specialized proprietary environment that only the incumbent supplier can operate.
- Independent security telemetry. Logs should flow into agency-controlled or separately managed systems wherever feasible.
- Skilled acquisition teams. Contract officers, program managers, architects, and security leaders need shared responsibility for assessing lock-in before contracts are signed.
Microsoft Still Has a Central Role to Play
A serious diversification strategy should not turn into reflexive anti-Microsoft policy. Microsoft’s federal products are deeply embedded because they solve real problems, and the company has made major investments in government cloud, zero-trust capabilities, endpoint defense, identity protection, and compliance tooling.The Defense Department’s recent enterprise agreement reflects the government’s continuing belief that Microsoft’s integrated services can support mission operations at scale. The department described the deal as a way to reduce fragmented procurement, create standardized configurations, and improve interoperability across military services and agencies.
Those benefits are genuine. Fragmentation can create its own security failures: inconsistent patching, unmanaged identities, incompatible encryption policies, shadow IT, unclear accountability, and inadequate support. A federal government with hundreds of incompatible tools and no common operational standards would not be more resilient simply because it had more logos in its data centers.
The policy objective, therefore, should be neither monopoly by default nor diversity for its own sake. It should be managed concentration: use shared platforms where they deliver genuine operational value, but limit the number of functions that depend on one vendor’s control plane and preserve credible alternatives for the most critical services.
Microsoft can be part of that solution. In fact, a supplier confident in its security, interoperability, and pricing should be able to compete effectively in a federal market that rewards portability rather than penalizes it.
The Contract Is the Most Practical Place to Start
The most important conclusion in “America Needs To Renegotiate Its Most Famous Software Marriage” is that the federal government created much of its present dependency through contracting, licensing, and procurement decisions. That means it can reduce the dependency through the same mechanisms.Congress does not need to order agencies to abandon Windows, Outlook, Azure, or Entra ID. It should insist that agencies know the cost of moving, can retain independent security evidence, and can sustain vital operations if one supplier suffers a major compromise or service failure.
A credible federal technology resilience agenda would require:
- Portability clauses in major cloud and software contracts;
- Transparent pricing for running licensed software across approved cloud environments;
- Baseline audit logging for government tenants without premium-tier dependency;
- Independent security-review rights for critical service providers;
- Supply-chain disclosure requirements for sensitive support work;
- Periodic workload portability exercises for high-value systems;
- Multivendor acquisition vehicles paired with real technical migration plans;
- Competition reviews where bundling, licensing, or contract structures materially limit government choice.
The federal government does not need a divorce from Microsoft. It needs a better contract—one that preserves the benefits of a powerful technology partner while ensuring that no single supplier’s mistake, breach, licensing decision, or support model can place too much of the government at risk all at once.
References
- Primary source: The Daily Wire
Published: 2026-07-27T16:29:05+00:00
America Needs To Renegotiate Its Most Famous Software Marriage
Every few months, an AI system arrives that makes the last one look quaint. The newest, a framework called Mythos, has been keeping policymakers and bank executives up at night for a specific reason: it showed how a single bug in an aging piece of Office software could hand an adversary the keys...www.dailywire.com
