OMB Memorandum M-22-09, issued January 26, 2022, put every federal civilian agency on a Zero Trust cybersecurity timeline. The mandate remains fully in effect. Follow-up guidance in OMB M-24-14 and OMB M-25-04 has continued to prioritize Zero Trust maturation as a federal budget and cybersecurity priority through FY2026, and FISMA reporting continues to measure agency progress against the original M-22-09 goals.
Most of the public conversation about Zero Trust focuses on identity, multi-factor authentication, and network segmentation, the software and policy layers of the CISA Zero Trust Maturity Model’s five pillars. What gets discussed far less is the hardware layer underneath all of it: the question of whether the device itself can be trusted before any identity or network control ever comes into play.
For federal IT buyers procuring computing hardware for Zero Trust environments, hardware-level security is not a nice-to-have feature. It is the foundation that the rest of the Zero Trust stack depends on being trustworthy.
M-22-09 organizes federal Zero Trust requirements around five pillars established by the CISA Zero Trust Maturity Model: identity, devices, networks, applications and workloads, and data. Each pillar includes specific objectives agencies were required to meet by the end of FY2024, with continued maturation expected through subsequent fiscal years under follow-up OMB guidance.
The Devices pillar is where hardware-level security becomes directly relevant to procurement decisions. M-22-09 requires that the federal government maintain a complete inventory of every device it operates and authorizes for government use, with capabilities to prevent, detect, and respond to incidents on those devices. That requirement cannot be satisfied by software monitoring alone if the underlying hardware cannot verify its own integrity.
The core tenet of Zero Trust is never trust, always verify. Most implementations focus that verification on users and network traffic. But a Zero Trust architecture that verifies every user and every network request while trusting the hardware underneath by default has a gap at its foundation.
If a device’s firmware has been compromised before the operating system even loads, every software-layer Zero Trust control running on top of that device inherits the compromise. Identity verification, network segmentation, and application-layer monitoring are all built on the assumption that the hardware executing them is behaving as intended. Hardware-level security establishes that assumption is actually true.
Pillar | What It Requires | Hardware Relevance |
Identity | Enterprise-managed identities, phishing-resistant MFA | Hardware security keys, TPM-backed credential storage |
Devices | Complete device inventory, prevent/detect/respond capability | TPM, secure boot, firmware integrity, hardware attestation |
Networks | Encrypted DNS and HTTP, micro-segmentation | Hardware-accelerated encryption, network interface security |
Applications and Workloads | Application-layer authorization, continuous testing | Secure enclave support for sensitive workload isolation |
Data | Data categorization, encryption at rest and in transit | Hardware-based encryption acceleration, secure key storage |
AI and HPC infrastructure often processes the most sensitive workloads in a federal agency’s environment: intelligence analysis, classified research, and mission-critical decision support systems. These are exactly the workloads where a hardware-level compromise would have the highest consequence, and exactly the workloads where procurement officers should apply the strictest hardware security evaluation criteria.
Federal procurement officers evaluating AI and HPC hardware should treat the following as standard evaluation criteria, not advanced or optional considerations:
Ace Computers configures federal AI and HPC systems with TPM implementation, UEFI Secure Boot support, and firmware integrity verification as standard practice, not as an add-on option. Every system built at our ISO 9001-compliant facility in Des Plaines, Illinois includes documentation of the firmware supply chain, supporting the device inventory and attestation requirements that M-22-09 and the CISA Zero Trust Maturity Model establish.
For federal programs with elevated security requirements, our engineering team works directly with agency security teams to validate that the hardware configuration supports the specific Zero Trust maturity level the program is targeting, whether that is the Traditional, Initial, Advanced, or Optimal tier of the CISA maturity model.
This is not a separate product line. It is how we build every system that leaves our facility for federal use, because hardware-level security is not a feature to bolt on after the fact. It has to be part of the platform from the start.
→ View Federal and Government IT Solutions
Yes. M-22-09 has not been rescinded or superseded. Follow-up OMB guidance, including M-24-14 issued in July 2024 and M-25-04 issued in January 2025, explicitly directs agencies to continue maturing their Zero Trust architectures beyond the original FY2024 deadline, and FISMA and CDM reporting continues to measure agency progress against M-22-09 goals.
M-22-09 does not mandate a specific hardware certification by name, but it requires device-level capabilities, including complete device inventory and the ability to prevent, detect, and respond to incidents, that are practically achievable only with hardware that supports TPM-based attestation, secure boot, and firmware integrity verification. Procurement officers should evaluate these capabilities directly rather than looking for a single named certification.
Yes. Ace Computers configures federal AI and HPC systems with TPM implementation, secure boot support, and firmware integrity verification as standard practice, and our engineering team works with agency security teams to validate configurations against specific Zero Trust maturity targets.
