Zero Trust Hardware Access: Extending the Federal Device Pillar

Federal agencies have made substantial progress in implementing Zero Trust. Identity controls are stronger, access decisions are becoming more contextual, and security teams have greater visibility across users, applications, workloads, data, and network activity.

This progress has been shaped by a broad body of federal policy and technical guidance, including OMB Memorandum M-22-09 (OMB), NIST Special Publication 800-207 (NIST), CISA’s Zero Trust Maturity Model (CISA), and Binding Operational Directive 23-01 (CISA). Together, these initiatives reinforce a central principle: access should not be granted because of network location or assumed trust. It should be based on continuously evaluated identity, context, policy, and risk.

Yet one important question often remains unresolved:

Can we trust the hardware requesting access?

When device identity depends primarily on software-reported information, network identifiers, credentials, or other attributes that can be copied or manipulated, the trust decision may rest on an incomplete foundation.

This creates a significant blind spot in federal Zero Trust architectures: hardware access may be assumed rather than independently verified.

The Problem: Hardware Is a Blind Spot in Federal Zero Trust

Executive Order 14028 (Federal Register) helped accelerate the federal government’s transition toward Zero Trust. OMB Memorandum M-22-09 (OMB) subsequently translated that direction into a government-wide implementation strategy organized around five pillars:

1. Identity
2. Devices
3. Networks
4. Applications and workloads
5. Data

The memorandum also identifies visibility, analytics, automation, orchestration, and governance as capabilities that span those pillars.

The inclusion of the device pillar is critical. Federal Zero Trust cannot depend solely on verifying users and applications. Agencies must also determine whether the endpoint, peripheral, infrastructure component, or connected asset participating in an interaction is known, authorized, compliant, and suitable for access.

Most federal Zero Trust programs evaluate questions such as:

• Who is requesting access?
• Is the user strongly authenticated?
• Is the endpoint managed?
• Does it meet required security and configuration policies?
• Is the requested action consistent with the user’s role?
• Does the transaction present an acceptable level of risk?

These are necessary questions, but they may not establish whether the connected hardware is genuinely what it claims to be.

Traditional discovery and security tools frequently rely on attributes such as:

• MAC and IP addresses
• Hostnames
• Certificates
• Operating-system information
• Installed agents
• Device-generated descriptions
• Network traffic patterns

These signals provide useful context, but many are self-reported, changeable, duplicable, or spoofable.

A rogue device may imitate a trusted endpoint. An unauthorized peripheral may present itself as a common keyboard or storage device. A hardware implant may operate transparently between legitimate systems. An unmanaged switch or passive network component may not behave like a conventional endpoint at all.

In these cases, an agency may believe that it has verified a device when it has actually verified only the identity presented by that device.

Spoofable signals can result in unverified access.

What Federal Guidance Already Tells Us

NIST Special Publication 800-207 (NIST) provides the foundation for federal Zero Trust, describing it a shift away from static, perimeter-based defences toward protection centred on users, assets, and resources. Trust should not be granted merely because an asset is located on an internal network or is owned by the organization.

This distinction is especially important for hardware.

A device should not automatically be trusted because it:

• Appears on an internal network
• Uses an approved IP range
• Presents a familiar MAC address
• Connects through an authorized port
• Claims to be a recognized device type
• Previously appeared in an inventory

NIST’s model supports access decisions based on a continuously evaluated operational picture using information from multiple sources.

From Sepio’s perspective, this creates an opportunity to extend federal Zero Trust device assurance beyond logical posture and configuration checks. Hardware identity and hardware-level risk can become additional inputs into the Zero Trust policy decision rather than assumptions made before that decision.

CISA’s Zero Trust Maturity Model Version 2.0 builds on this foundation and helps agencies progress from traditional practices toward advanced and optimal capabilities across the five pillars.

Within the device pillar, agencies are expected to improve their ability to inventory, assess, monitor, and respond to device risk. Achieving more mature device assurance, however, requires agencies to consider not only whether an endpoint has an agent or conforms to a configuration baseline, but also whether the connected physical asset is actually the asset the organization expects.

Asset Visibility Is Essential for Federal Zero Trust, but Visibility Must Be Complete

CISA’s Binding Operational Directive 23-01: Improving Asset Visibility and Vulnerability Detection on Federal Networks (BOD 23-01) reinforces the importance of continuous asset discovery and vulnerability enumeration.

The directive applies to Federal Civilian Executive Branch agencies and requires them to improve their ability to identify assets and vulnerabilities and provide relevant information through the Continuous Diagnostics and Mitigation ecosystem. It does not apply to statutorily defined national security systems or certain systems operated by the Department of Defense and Intelligence Community.

The directive reflects an important operational reality:

• Agencies cannot protect assets they do not know exist.

But two additional questions must also be addressed:

• Does the inventory include assets that do not respond to traditional discovery methods?
• Does the discovered identity accurately represent the connected physical hardware?

A scanner may identify that an IP address is active. An endpoint platform may report an installed operating system. A network-management system may record a MAC address. These observations help build an inventory, but they may not identify:

• Transparent network devices
• Unmanaged switches
• Unauthorized peripherals
• Hardware implants
• Devices without agents
• Assets that generate little or no conventional network traffic
• Devices masquerading as approved equipment
• Hardware connected through unmanaged or unsupervised interfaces

Asset discovery tells an agency what appears to be present.

Hardware identity verification asks a deeper question:

• What is the asset really?

Strengthening CISA Continuous Diagnostics and Mitigation Asset Management

CISA’s Continuous Diagnostics and Mitigation program (CDM) supports federal agencies through capabilities covering asset management, identity and access management, network security management, and data protection.

Continuous Diagnostics and Mitigation Asset Management capabilities help agencies understand what assets exist, where they are located, how they are configured, and which systems may require attention.

Hardware-level intelligence can strengthen this data by helping agencies:

• Discover assets missed by conventional tools
• Identify devices without installed agents
• Detect inconsistencies between claimed and observed identities
• Find unauthorized infrastructure and peripherals
• Reduce inaccurate or duplicate inventory records
• Add hardware-specific risk context
• Prioritize remediation based on actual exposure

The objective should not be to create another isolated inventory.

The objective should be to enrich Continuous Diagnostics and Mitigation, agency dashboards, configuration-management databases, and other authoritative repositories with more complete and independently verified hardware information.

Supporting FISMA and the NIST Risk Management Framework

The Federal Information Security Modernization Act (FISMA) establishes government-wide responsibilities for protecting federal information and information systems.

For agencies implementing federal Zero Trust under the NIST Risk Management Framework (NIST), hardware visibility and identity verification can provide supporting technical evidence for several areas addressed by NIST SP 800-53 Revision 5 (NIST), including:

• CM-8 – System Component Inventory
• CA-7 – Continuous Monitoring
• IA-3 – Device Identification and Authentication
• SI-4 – System Monitoring
• SR-10 – Inspection of Systems or Components, where applicable
• Configuration management
• Access enforcement
• Supply-chain risk management
• System integrity
• Incident monitoring and response

For example, CM-8 calls for organizations to develop and maintain an accurate inventory of system components and update it as components are installed or removed.

A hardware-aware approach can make that inventory more dependable. Instead of relying only on logical identifiers, agencies can add independently observed hardware characteristics and risk indicators that help determine whether a connected component matches its approved record.

This can provide supporting evidence for assessors, authorizing officials, system owners, and security operations teams by helping answer:

• Is the asset recorded in the inventory actually present?
• Is the connected hardware the same asset that was authorized?
• Has a device been replaced, altered, or moved?
• Is an unapproved component participating in the system?
• Is the asset connected in an unexpected location?
• Do its hardware, connection, or infrastructure characteristics conflict with its approved identity and role?

This is the difference between maintaining a list and maintaining trustworthy evidence.

Department of Defense Zero Trust Also Depends on Device Assurance

The Department of Defense Zero Trust Strategy and Roadmap (now U.S. Department of War) establishes a department-wide approach to moving beyond perimeter-centric security. It defines capabilities intended to protect DoW data and systems through explicit and continuously evaluated trust decisions.

For DoW environments, the hardware question is especially significant.

Mission systems may include:

• Conventional IT endpoints
• Tactical systems
• Operational technology
• Industrial control systems
• Laboratory and test equipment
• Specialized communications equipment
• Internet of Military Things devices
• Contractor-managed assets
• Legacy platforms
• Removable media and peripheral devices

Many of these environments cannot easily accommodate heavy traffic inspection, intrusive scanning, or endpoint agents. Some include devices that were never designed to report identity or security posture to modern management platforms.

Zero Trust Hardware Access (ZTHA) can complement DoW Zero Trust implementation by creating additional assurance around the devices participating in mission workflows, particularly where logical identity alone is insufficient.

The Shift: From Asset Inventory to Hardware Identity Verification

Federal agencies already recognize that asset inventory is foundational to cybersecurity, compliance, vulnerability management, incident response, and operational resilience.

But inventory alone is not enough.

An inventory confirms that an asset has been recorded or observed.

Hardware identity verification helps determine whether the asset is authentic, expected, and suitable for access.

This requires a shift in mindset:

From “What is connected?” to “What is it really, and should it be trusted?”

A hardware-aware Zero Trust capability should help agencies identify:

• Known and unknown assets
• Managed and unmanaged devices
• Network infrastructure
• Transparent hardware
• Unauthorized peripherals
• Devices masquerading as approved assets
• Hardware whose observed characteristics do not match its reported identity
• Assets connected in unexpected locations
• Components whose hardware identity changes over time

This verification must also operate at federal scale.

Hardware identity verification should be deployable without requiring traffic mirroring, packet decryption, or universal endpoint-agent coverage-particularly across distributed facilities, legacy environments, operational systems, air-gapped networks, and sensitive mission locations.

Hardware identity should become an additional source of authoritative context feeding the broader Zero Trust architecture.

The Practice: Closing the Hardware Trust Gap

Closing the gap does not require agencies to replace their existing Zero Trust investments. It requires extending those investments so that hardware identity and hardware risk become part of access, authorization, and response decisions.

Establish continuous visibility across the full environment

Agencies should identify all connected hardware, not only assets with agents, credentials, IP addresses, or supported operating systems.

Coverage should include endpoints, servers, switches, operational systems, IoT devices, peripherals, transparent components, and unmanaged assets.

This can support agency efforts related to BOD 23-01 asset-visibility objectives, CDM Asset Management, FISMA continuous monitoring , and NIST SP 800-53 component-inventory activities.

Validate hardware identity beyond self-reported attributes

Device trust should not depend exclusively on information supplied by the device.

Agencies should compare claimed identity with independently observed hardware characteristics. A mismatch between logical identity and physical characteristics should be treated as a risk indicator requiring investigation.

Translate hardware observations into risk

Not every unknown device presents the same level of exposure. Federal teams need context that helps prioritize action.

Relevant indicators can include:

• Unexpected device category
• Rare or previously unseen hardware
• Identity inconsistency
• Unexpected connection location
• Unsupervised host or network infrastructure
• Abnormal port characteristics
• Unauthorized peripheral activity
• Changes in observed device attributes
• Known vulnerability or threat exposure

These findings should contribute to a consistent risk assessment that can inform policy and remediation.

Integrate hardware intelligence with existing federal security infrastructure

Verified hardware information should enrich the tools agencies already use, including:

• CDM and agency dashboards
• Configuration-management databases
• Network access control
• Endpoint security platforms
• SIEM and security analytics
• SOAR and case-management systems
• Vulnerability-management platforms
• IT service-management systems
• Zero Trust policy engines

This supports the cross-pillar visibility, analytics, automation, and orchestration envisioned by OMB and CISA.

Convert visibility into enforceable policy

When a device is unknown, unauthorized, or inconsistent with its approved identity, agencies should be able to initiate proportionate actions such as:

• Generating an alert
• Opening an incident
• Updating the authoritative asset record
• Requiring additional validation
• Restricting access
• Moving the device to a controlled segment
• Isolating the asset
• Initiating forensic or physical inspection

The response should be based on mission context and risk, not simply on whether the device appears in an inventory.

Measure trust continuously

Zero Trust is not a one-time approval.

A device that was trusted yesterday may be replaced, moved, reconfigured, tampered with, or connected through a different interface today.

Agencies should continuously determine whether hardware still matches its expected:

• Identity
• Type
• Location
• Role
• Connection
• Configuration
• Risk profile

This supports the federal objective of moving from periodic compliance toward continuous, evidence-based security.

How Sepio Extends Federal Zero Trust

Sepio extends federal Zero Trust programs with trafficless asset discovery and hardware identity intelligence across IT, OT, IoT, and peripheral environments.

By using infrastructure telemetry and physical-layer device characteristics, Sepio helps agencies identify known, unknown, unmanaged, transparent, and potentially masquerading assets without requiring network traffic collection, packet decryption, sensors, or probes.

Sepio’s hardware-level insights can enrich existing CDM, CMDB, NAC, SIEM, SOAR, ITSM, vulnerability-management, and policy-enforcement workflows. This enables agencies to strengthen current investments rather than introduce another disconnected security silo.

The result is not simply a more complete asset inventory. It is a more reliable basis for determining whether a device should be trusted, investigated, restricted, or isolated.

Hardware Must Become Part of the Federal Zero Trust Decision

OMB, CISA, NIST, DHS, and the Department of Defense (now U.S. Department of War) have established a strong foundation for federal Zero Trust.

The next step is to ensure that the device pillar reaches the physical layer.

An asset should not be trusted merely because it presents a familiar MAC address, hostname, certificate, or operating-system profile. Federal agencies need confidence that the hardware itself is authentic, authorized, and consistent with policy.

Zero Trust Hardware Access (ZTHA) can help agencies:

• Improve the completeness and accuracy of asset inventories
• Support agency efforts related to BOD 23-01 asset-visibility objectives
• Strengthen CDM Asset Management data
• Provide supporting evidence for selected FISMA and NIST RMF activities
• Advance the CISA Zero Trust device pillar
• Support DoD device and mission-system assurance
• Enrich policy engines with hardware-level risk
• Detect unauthorized or masquerading devices
• Turn hardware visibility into operational response

The principle behind federal Zero Trust is clear:

Never trust implicitly. Verify explicitly and continuously.

That principle should apply not only to users, credentials, applications, and data, but also to every physical device requesting access.

Because a federal Zero Trust architecture cannot be complete until the hardware is verified too.

Talk to Sepio about Federal Zero Trust Security

Discover how Sepio helps federal agencies strengthen Zero Trust security by verifying device identity, detecting unauthorized hardware, and reducing risk through hardware-level visibility aligned with the Federal Device Pillar.