New cyber strategy shifts attention to cloud and supply chain security

In a recent commentary, I outlined five IT security trends that are top of mind for federal cybersecurity experts. That commentary captured the mood at the time—a landscape defined by data security posture management, edge security, and the persistent challenges of zero trust, AI and quantum. Since then, the playing field has evolved.

As of this writing, several of those priorities are being reshaped by the National Cybersecurity Strategy released on March 6, 2026. Zero trust, AI security and post-quantum cryptography still take center stage, but cloud security and supply chain security are eclipsing—for the moment—data security posture management (DSPM) and edge security. For federal IT contractors and employees, this shift has direct implications for procurement decisions, compliance obligations, and the day-to-day work of securing government systems.

This commentary breaks down what federal IT professionals need to know about the new strategy—and what to do about it. We’ll walk through the strategy’s overarching framework, then move into practical guidance on cloud data protection and software supply chain security.

What is the National Cybersecurity Strategy?

The strategy calls for unprecedented coordination across government and the private sector, promoting investment in technology and innovation, while deploying America’s cyber capabilities for both offensive and defensive missions.

Practically speaking, this means accelerated modernization, defensibility, and resilience of federal information systems, through cybersecurity best practices, post-quantum cryptography, zero-trust architecture, and cloud transition. The strategy also specifically calls for the adoption of AI-powered cybersecurity solutions to defend networks and deter intrusions at scale—a recognition that the speed and sophistication of modern threats outpaces what human operators alone can manage.

The strategy organizes its priorities around six pillars of action, each of which carries implications for federal contractors and agency cybersecurity teams:

Shape Adversary Behavior: Deploy the full suite of U.S. government defensive and offensive cyber operations. Detect, confront, and defeat cyber adversaries before they breach networks and systems. This pillar implies the need for better supply chain security—specifically software bills of materials (SBOMs), which we’ll examine in detail later.

Promote Common Sense Regulation: Streamline data and cybersecurity regulations, and ensure the private sector has the agility to keep pace with rapidly evolving threats. This pillar also touches on supply chain security, with an emphasis on giving vendors workable compliance frameworks rather than overlapping mandates.

Secure Critical Infrastructure: Identify, prioritize, and harden America’s critical infrastructure, including the energy grid, financial and telecommunications systems, data centers, water utilities, and hospitals.

Modernize and Secure Federal Government Networks: Accelerate modernization through cybersecurity best practices, post-quantum cryptography, zero-trust architecture, and cloud transition. For IT contractors supporting federal agencies, this pillar is the most directly actionable: It describes a mandate to move faster and smarter on cloud adoption.

Sustain Superiority in Critical and Emerging Technologies: Promote adoption of post-quantum cryptography and secure quantum computing, and secure the AI technology stack, including data infrastructure and AI models.

Build Talent and Capacity: America’s cyber workforce is a strategic asset. Eliminate roadblocks that prevent industry, academia, government, and the military from building a highly skilled cyber workforce.

Because my previous commentary covered several of these technology initiatives in detail, let’s focus here on the two areas that I believe should receive more immediate attention: Cloud data protection best practices and supply chain security through SBOMs.

Best Practices for Cloud Data Protection

At its most basic, cloud security means rethinking how data in the cloud is protected across its entire lifecycle.

Data protection in the cloud must account for three distinct states: Data at rest, in use, and in transit.

Data at rest is in an “inactive” state, stored as structured data in databases and unstructured data in files, etc. Data in use is active and being manipulated—such as a row being operated on in a database, or data being processed by a CPU. Data in transit is being transported from one location or medium to another, such as across a network. Security controls must defend against all applicable threats in each of these states, including side-channel attacks that extract information from valid device operations rather than from a known vulnerability.

What’s often overlooked in cloud security is the need for a separation of duties—specifically, separation between entities that process and store data and those providing security services. In practical terms, this means that the cloud storage provider and the encryption and key management service provider should ideally be separate entities.

While major cloud providers such as Google, Amazon Web Services, and Microsoft Azure encrypt data both during transmission and before storage, they also hold the encryption keys for that stored data. They have direct access to everything residing on their servers, and that means, data owners have to trust the security of the cloud provider. That’s not ideal, to say the least.

To address this, a growing number of enterprises are separating encryption and key management from their cloud service. There are two primary models to consider: third-party encryption and data-origin encryption.

In the third-party encryption model, a separate encryption server, such as a Cloud Access Security Broker (CASB), sits between the customer and the storage provider, encrypting data before it is sent. In the data-origin encryption model, encryption is performed entirely on the customer side, as close as possible to where the data is generated, such as via a browser agent or application-level encryption.

Major cloud service providers now offer approaches that allow customers to serve as their own key custodians. These include Bring Your Own Key (BYOK), Hold Your Own Key (HYOK), and Bring Your Own Encryption (BYOE). While BYOE offers the strongest separation of trust, BYOK and HYOK meet many high-assurance and regulatory compliance requirements. For federal agencies and contractors operating under strict compliance mandates, these models are worth evaluating carefully and incorporating into cloud procurement criteria.

Understanding Supply Chain Security

Validating the integrity of IT products’ supply chains has been a critical component of cybersecurity for years. In the wake of major data breaches caused by malicious code introduced during the software development process, the level of scrutiny once applied to hardware bills of materials (HBOM) is now being applied to software as well. The result is the emergence of the Software Bill of Materials (SBOM).

The SBOM concept has been part of federal cybersecurity policy as far back as the 2023 National Cybersecurity Strategy. This iteration of the strategy specifically required software supply chain risk mitigation, including SBOM efforts, NIST’s Secure Software Development Framework, and improvements to open-source software security. The Executive Order on Improving the Nation’s Cybersecurity (EO14028) placed the responsibility for supply chain security guidance on the Secretary of Commerce and NIST, including the requirement that software vendors provide a SBOM for each product sold to the government, either directly or by publishing it on a public website.

The emphasis on SBOMs is part of the broader government-wide push to “bake-in” cybersecurity for products sold to the government, shifting responsibility away from agencies and placing it on vendors and integrators. The Cybersecurity and Infrastructure Security Agency (CISA) describes SBOMs as a key building block in software security—essentially a list of ingredients that make up software components. But an ingredients list is not a recipe. What is missing from many SBOM discussions is the process by which those components are incorporated into a product or solution, and how vulnerabilities in those components are identified and remediated over time.

Vendors bear real responsibility here. The federal government has more work to do to guide the vendor community toward appropriate SBOM tools, so that compliance is less of a manual, time-consuming process. One promising path forward would be enabling vendors to cross-reference SBOM components against the National Vulnerability Database. That kind of automated linkage would allow for rapid identification of vulnerabilities in integrated solutions and enable more reliable SBOM validation.

If products and solutions are genuinely to be “secure by design,” as CISA has termed it, the government must establish more comprehensive requirements with defined compliance milestones. Aspirational language in strategy documents is a starting point, but federal IT contractors need specific, measurable expectations they can build into product roadmaps and contract deliverables.

The bottom line for federal IT professionals is this: The new National Cybersecurity Strategy is not some distant policy document. It is a near-term operational directive. In addition to the trends outlined in my previous commentary, Cloud security and supply chain security are areas where agencies and contractors will feel the most pressure soonest.

Organizations must get ahead of these requirements. By implementing rigorous key management practices, building SBOM capabilities into their software development pipelines, and engaging seriously with Secure by Design principles, they will be better positioned both for compliance and for the broader mission of securing federal systems against increasingly sophisticated adversaries.