DHS excludes DeepSeek and third-party products from federal civilian IT and procurement

The US Department of Homeland Security orders federal civilian agencies to remove DeepSeek and affiliated products from their IT systems, bar them from procurement and also inspect third-party products that use DeepSeek. The lesson for every organisation: you can only exclude an AI model if you can also identify integrated services and the full supply chain.

On 20 October 2026 the Federal Register published a DHS order that excludes DeepSeek products from the IT systems and procurements of federal civilian executive branch agencies. The order covers third-party products and services developed using DeepSeek implementations. According to the publication, exception procedures exist for substantiated requests.

What exactly has the DHS decided about DeepSeek?

The DHS directs federal civilian agencies to remove DeepSeek and affiliated products from their information systems, to block future acquisition and to include third-party products and services developed using DeepSeek implementations within the measure. Reporting by Quartz shows that the measure goes beyond the vendor's own app or API and also affects third-party products that process DeepSeek.

• Removal of DeepSeek and affiliated products from federal civilian IT systems.
• Exclusion of DeepSeek and affiliated undertakings from future procurement.
• Coverage of third-party products and services developed using DeepSeek implementations.
• Exception possibilities via a substantiated request.

According to reporting by 7minAI News, the underlying order was signed on 24 July 2026 under the Federal Acquisition and Supply Chain Security Act and only made public in October. It is therefore a procurement and supply-chain measure, not a stand-alone security warning.

Does this ban also apply to companies outside the federal government?

No. The order is aimed at federal civilian executive branch agencies of the US government. It is not a general ban on DeepSeek for all US companies, hospitals, law firms or private individuals. Anyone not covered by the federal civilian government is not legally bound by this order.

Even so, its significance is broader than its target group. In our assessment, the order is above all an example of how an authoritative purchaser assesses an AI supplier for the risks of data access and provenance, and translates that judgement into hard procurement and removal requirements. With this publication the DHS has not established that every use of DeepSeek leads to a data breach; it has deemed the risk unacceptable for federal civilian systems and attached a targeted measure to that.

Why does the measure reach beyond the visible DeepSeek app?

Our analysis is that an AI model need not appear only in a recognisable app: it may run through an API under the bonnet of another product, serve as a building block in an integrated service, or be used through a subprocessor in a chain an end user never sees. By also covering third-party products, the DHS order illustrates what our analysis identifies as a practical consequence: organisations seeking to exclude a model need visibility into relevant dependencies in the service chain.

The order leaves one practical question open: how does an agency establish whether a third-party product contains a DeepSeek implementation? Our analysis on this: that requires more than a list of visible AI tools. It requires that, for each application, it is known which model, which provider, which API and which subprocessor sit behind the service, and which data flows along that route.

What does this decision mean for directors, lawyers and CISOs?

Our analysis: because the DHS also affects third-party products that use DeepSeek, an inventory of visible AI apps no longer suffices for organisations working with sensitive information; the CISO must therefore record, for each AI application, which underlying model and which provider, API and subprocessor sit behind it, and start this month with the systems of highest data sensitivity. Because the order combines removal and procurement exclusion, the risk also touches contracts and purchasing; the lawyer must therefore now contractually require suppliers to declare their AI subprocessors and model provenance and to report any change, so that a prohibited component is later demonstrably replaceable. Because a model can still process data via an invisible route, there is a risk that sensitive information runs along a non-approved provider; the responsible director must therefore have non-approved model routes blocked technically rather than merely prohibited in policy. Because the order includes exception procedures, it shows that an exclusion is a reviewable decision and not an automatism; the organisation must therefore keep, for each model, the assessment, the removal or the approved exception separately and verifiably, so that at an audit it is traceable who decided what and when.

As a summary of that analysis, a short checklist:

1. Inventory models and third-party components, not only the visible apps.
2. Link each component to its owner, version, location, access rights and processed data.
3. Test contractual and technical replacement options for each supplier.
4. Block non-approved model routes technically, not only in policy.
5. Keep evidence of assessment, removal, exception or approval.

Anyone who skips these steps runs the risk that a later prohibited or unwanted model still processes data through a service that nobody had registered as an AI component. The theme fits into broader discussions about the topic hub on AI security and threat management, about establishing data residency per processing step, about risks in AI training data and pipelines and about treating AI risk as a system-wide resilience problem.

Sources: The article draws on the DHS order in the Federal Register and on reporting by Quartz and 7minAI News about its scope.