Overview

As zero‑trust architectures move deeper into the infrastructure stack, the question of where to enforce controls — on the host (kernel/eBPF, sidecars, host agents) or on programmable SmartNICs/DPUs — is now operational reality for many organizations. Since our June 2026 analysis, adoption patterns, vendor capabilities and threat research have evolved. This September 2026 update maps what has changed, highlights concrete evidence and gives actionable guidance for architects choosing an enforcement plane today.

Background: why the choice still matters

DPUs (data processing units) are now a mainstream SKU across hyperscalers and enterprise server vendors: they offload packet processing, TLS/crypto, flow telemetry and isolation from host CPUs. Host enforcement using kernel hooks, eBPF, sidecars and agents remains strong because it can access process identity, OS context and rich telemetry that DPUs historically could not.

Since mid‑2024 the market has moved from proof‑of‑concepts to production pilots. Two clear trends accelerated in 2025–2026: (1) DPUs now commonly run sandboxed runtimes (notably WebAssembly and constrained eBPF offload), improving code portability and safety; and (2) standardization efforts — for policy translation and telemetry schemas — have made hybrid deployments operationally tractable.

Data and evidence: what changed since June 2026

  • Runtimes and portability: By 2026 several major DPU SDKs added first‑class WebAssembly (WASM) support and a stabilized eBPF offload ABI. That matters because WASM lets teams push small, auditable policy modules to the DPU with clearer isolation than raw Linux binaries.
  • Standards momentum: Industry working groups and OSS projects focused on DPU policy translation (XACML/OPA→DPU rule compilers) and telemetry normalization gained traction. This reduced the manual rule‑mapping previously required between control planes and NICs.
  • Security research and incidents: Public security research in 2025–2026 exposed firmware and management plane vulnerabilities in several widely deployed SmartNIC models. Those disclosures forced operators to adopt stronger firmware SBOMs, signed updates, and continuous attestation in DPU lifecycles.
  • Operational deployments: Large telcos and cloud providers expanded DPU use in 2026 where line‑rate processing and deterministic latency were priorities (edge compute, vRAN, storage acceleration). For many enterprises, the early pattern is targeted DPU use in high‑throughput zones and a retainment of host enforcement for identity‑rich workloads.

Where DPUs now clearly add value

  • Deterministic, line‑rate enforcement: Modern DPUs apply TLS termination, L4/L7 filtering and flow classification at near line rate while keeping host CPU contention low — valuable for telco slices, CDN edges and data‑intensive analytics clusters.
  • Lower noise for detection pipelines: Offloading sampling and packet capture to the DPU reduces host perturbation and helps produce high‑fidelity flow telemetry without degrading application performance.
  • Sandboxed policy modules: WASM and constrained eBPF offload on DPUs makes it feasible to deploy smaller, auditable enforcement modules that are easier to review than large monolithic firmware images.

Updated security trade‑offs

Shifting enforcement onto DPUs continues to reshape the trusted computing base (TCB). The balance has shifted slightly since June 2026 in two ways: better runtime isolation reduces risk from arbitrary code execution on the DPU, but firmware and supply‑chain risks remain elevated.

  • Improved isolation: WASM runtimes and read‑only policy images reduce the likelihood that a buggy third‑party agent compromises the whole DPU.
  • Firmware and management plane remain critical: Attacks against DPU firmware or the manufacturer's update infrastructure can still produce systemic risk. Operators report that rigorous SBOMs, signed updates and layered attestation (hardware root of trust + remote verification) are no longer optional.
  • Remote attestation practices matured: In 2026 it's become best practice to tie DPU attestation into the same continuous verification pipelines used for hypervisors and BMCs — attestation reports must be consumed by the central policy plane before rules are accepted.

Policy consistency and orchestration: the hybrid truth

One persistent operational problem is rule drift between control planes and multiple enforcement targets. Since mid‑2026, solutions and patterns that reduce that friction have become usable in production:

  • Compile once, target many: Central policy engines (OPA/XACML variants or enterprise controllers) now commonly implement back‑ends that emit DPU‑optimized rules and host‑side policies from a single intent model, reducing divergence.
  • Rule split by capability: The recommended model remains: put flow‑level, crypto and deterministic filtering on DPUs; keep process identity, OS attributes and in‑process policy on hosts. Newer toolchains automate that split rather than requiring manual rule authoring.
  • Continuous reconciliation: Operators have adopted automated audits that compare intended rules against what's active on host agents and on DPUs; those audits should be part of CI/CD for policy changes.

Telemetry, forensics and observability — updated playbook

DPUs enrich observability but introduce mapping challenges. Key practices that emerged in 2026:

  • Ship DPU telemetry with tamper‑proof metadata (signed attestation context, timestamps and DPU‑aligned SBOM references).
  • Enrich flow records on ingestion with host identity signals (instance id, container/pod id, process hash) to make DPU data actionable in SIEM/SOAR workflows.
  • Design playbooks that explicitly account for DPU failure or compromise: ensure host agents can immediately elevate logging and local enforcement if DPU telemetry disappears or attestation fails.

Operational lifecycle: stricter requirements in 2026

  1. Firmware SBOM and signed updates: Demand vendor SBOMs and require signed, verifiable update pipelines. Track firmware provenance into asset inventories.
  2. Attestation gating: Policy pushes should be gated on successful remote attestation. Use short‑lived credentials and rotate keys tied to a hardware root of trust.
  3. Failure mode testing: Incorporate DPU failover tests into chaos engineering: simulate DPU loss, corrupt attestation, and update failures; validate fallbacks to host enforcement under realistic load.
  4. Staffing and playbooks: Add firmware and NIC‑management expertise to networking and security teams; cross‑train SREs on DPU telemetry and recovery procedures.

When to choose DPUs, host enforcement, or a hybrid today

The practical guidance from live pilots and operator feedback in 2026 crystallizes into three clear patterns:

  • Choose DPUs when: You need deterministic, line‑rate encryption/termination or you run latency‑sensitive east‑west workloads whose host CPUs are saturated. Also choose DPUs where centralized telemetry at scale drives analytical advantage.
  • Choose host enforcement when: Policies require deep process context, kernel‑level hooks or integrations with endpoint security that cannot — and likely should not — be pushed into a network fabric element.
  • Choose hybrid for most enterprises: Use DPUs for network‑centric controls and telemetry; keep identity and process‑centric enforcement on hosts. Automate the policy split and reconciliation; require attestation and fallback behavior as non‑negotiable.

Cost, vendor lock‑in and portability — updated cautions

DPUs now come with clearer TCO components: hardware cost, firmware lifecycle, additional orchestration, and longer OS/hardware refresh cycles. A few pragmatic controls to reduce lock‑in:

  • Prefer vendors that support WASM and standardized telemetry formats to ease policy portability.
  • Architect central policy engines to emit neutral primitives that can be compiled to vendor‑specific bytecode rather than baking business logic into proprietary NIC tools.
  • Negotiate firmware SLAs and access to SBOMs during procurement.

Practical recommendations for zero‑trust architects (Sept 2026)

  • Treat DPUs as first‑class elements in your trust perimeter: require SBOMs, signed firmware, and continuous attestation before deploying rules.
  • Standardize on a single intent‑based policy model and adopt toolchains that emit both host and DPU artifacts automatically (WASM modules for DPUs, eBPF/iptables rules for hosts, etc.).
  • Automate reconciliation and chaos tests: simulate DPU compromise and validate automatic host fallback enforcement and extended logging.
  • Start via targeted pilots: choose an internal high‑throughput cluster or edge slice where performance gains can be measured and rollback is safe.
  • Plan telemetry correlation from day one: ensure DPU flow records are joinable to host process identity and orchestration metadata to keep investigations fast.

Multiple perspectives

Practitioners running hyperscale or telco stacks emphasize the performance and observability wins of DPUs. Security teams caution that DPUs transfer, not remove, critical risk — making firmware hygiene and attestation top priorities. Vendors point to WASM as a way to reconcile portability and safety; open‑source contributors stress the need for standard ABIs and telemetry schemas to avoid lock‑in. The common ground: a hybrid, automated model is the practical path forward.

Implications for readers

If you are an architect or security lead evaluating enforcement planes, the immediate tasks are:

  • Inventory where deterministic line‑rate enforcement would materially improve performance or reduce host costs.
  • Establish firmware governance (SBOMs, signed updates) and integrate DPU attestation into your CI/CD gates.
  • Adopt policy tooling that emits both DPU and host artifacts from a single intent model to avoid drift.

Outlook: what to watch for next

Through 2027 expect three developments to matter:

  • Broader adoption of WASM runtimes on DPUs and standardized eBPF offload ABIs, improving portability and safety.
  • More mature supply‑chain controls (SBOMs, attestation marketplaces) tied to firmware ecosystems.
  • Consolidation of tooling that compiles intent into both host and DPU policies, reducing operational friction for hybrid enforcement.

Those trends make DPUs an increasingly practical component of zero‑trust architectures — provided organizations treat firmware, attestation and reconciliation as first‑order problems.

FAQ

Are DPUs a full replacement for host‑based enforcement?

No. DPUs excel at line‑rate, network‑centric controls and telemetry but lack innate access to per‑process OS context. Most practical deployments in 2026 use a hybrid model: DPUs for deterministic network policies and hosts for identity/process‑centric checks.

How important is firmware attestation for DPUs?

Critical. Public research in 2025–2026 showed firmware and update plane weaknesses; strong SBOMs, signed updates and remote attestation are now baseline controls. Without them, DPU enforcement undermines, rather than strengthens, zero‑trust guarantees.

Can I use existing policy tools for DPUs?

Partially. Modern policy engines can emit host and DPU artifacts, but you should validate the toolchain’s DPU back‑ends (WASM/eBPF support), telemetry formats and reconciliation features before committing to a vendor.

What should I pilot first?

Start with a high‑throughput, non‑customer‑facing segment (internal analytics, a telco slice or an edge cache cluster). Measure latency, host CPU impact and telemetry quality; exercise firmware updates and failover tests.

What’s the single most important operational control?

Automated attestation gating: require proof of secure boot and signed runtime images before any DPU accepts enforcement rules. Combine that with continuous reconciliation to detect drift or tampering quickly.