The U.S. Department of Homeland Security has ordered civilian executive-branch agencies to remove DeepSeek products from their information systems and stop buying technology from the Chinese AI company. The directive also covers affiliated companies and third-party products or services developed using DeepSeek implementations, a scope that reaches beyond the DeepSeek app and hosted API.
DHS disclosed the order in a Federal Register notice filed for public inspection on October 19 and scheduled for publication on October 20. The underlying Exclusion and Removal Order 2026-01 was signed on July 24 under the Federal Acquisition Supply Chain Security Act of 2018, or FASCSA.
For agencies and contractors, the immediate problem is discovery. DeepSeek models can appear as direct API connections, downloaded model weights, container images, fine-tuned derivatives, components inside agent platforms, or an upstream dependency that a software vendor never exposed in its product name. A block on a website or mobile app will not find all of those uses.
What the DeepSeek order covers
The procurement side bars federal civilian agencies from acquiring information technology products and services developed by Hangzhou DeepSeek Artificial Intelligence Co. and its affiliates. The removal side is broader: it applies to DeepSeek and affiliate products already in agency IT, plus third-party products and services developed using DeepSeek implementations.
That wording makes the model layer, not merely the vendor relationship, relevant. A contractor could run open-weight DeepSeek models on U.S. infrastructure without sending prompts to DeepSeek’s servers, yet the product may still fall within the order’s third-party language. The public notice does not distinguish between DeepSeek’s hosted service and a self-hosted deployment.
The order applies to Federal Civilian Executive Branch agencies, except for national-security systems and sensitive compartmented information systems. Those exclusions do not amount to permission to use DeepSeek in military or intelligence environments; other authorities govern those systems. The fiscal 2026 intelligence authorization law already required standards for removing covered DeepSeek applications from intelligence-community national-security systems.
FASCSA orders are mandatory for agencies within their stated scope. A CISA implementation overview explains that agencies may have to remove covered technology, exclude it from purchasing and report compliance through CyberScope. Individual orders can also provide a route for agencies to seek exceptions when immediate removal is not practical.
Why DHS classified DeepSeek as a supply-chain risk
The signed order describes several risk paths. It points to DeepSeek’s China-based infrastructure and the possibility that government employees or vendors could transfer sensitive information through prompts, uploaded files, telemetry or account data. It also cites security concerns in DeepSeek software and the prospect of vulnerabilities or malicious code reaching government environments.
DHS framed the decision as a supply-chain action rather than a general consumer ban. Private companies, state governments, Congress and the federal courts are not directly ordered to remove DeepSeek by this document. The action does, however, matter to companies selling software or services into civilian agencies because their own use of DeepSeek can bring an otherwise unrelated product into scope.
The timing is striking. Two days before the public notice, DeepSeek opened new Search and Fetch APIs for agents and retrieval systems. Its developer documentation describes raw JSON endpoints that use the same bearer authentication as its model API and can return search results or fetch a page as Markdown. Those services create another integration point that federal vendors need to identify, even when DeepSeek is not the model generating the final answer.
What agencies and federal vendors should inventory
A useful review starts with more than a list of approved chatbots. Security, procurement and engineering teams should build one inventory that covers direct services, model artifacts and indirect dependencies.
- API and network use: Search source code, secrets managers, egress logs and API gateways for DeepSeek hostnames, API keys and SDK configuration. Include the new Search and Fetch endpoints, not only chat-completion traffic.
- Model registries: Check Hugging Face caches, internal artifact stores, MLflow or equivalent registries, container layers and inference servers for DeepSeek model names, hashes and fine-tuned descendants.
- Agent and coding tools: Review IDE extensions, command-line agents, RAG services and model routers. A workflow may call DeepSeek only as a fallback, search provider, evaluator or subagent.
- Vendor products: Ask suppliers to identify any DeepSeek implementation used to deliver the product or service, including self-hosted weights and subcontractor components. A generic claim that customer data stays in the United States does not answer the model-provenance question.
- Procurement systems: Remove covered offerings from catalogs, blanket purchase vehicles and renewal queues. Check statements of work and technical proposals for model-agnostic language that could allow a vendor to substitute DeepSeek later.
- Evidence and replacement: Preserve configuration, logs and contract records before removal, then map each use to an approved replacement. Teams should test output quality, latency, cost and safety controls rather than assuming that swapping model names is operationally neutral.
Teams also need a definition for derivatives. A fine-tune, quantized build or merged model may no longer carry a simple deepseek label, while model cards and training records still show its lineage. Procurement questionnaires should therefore ask about base models and training provenance, not just the commercial name displayed to users.
The third-party clause is the difficult part
Previous workplace restrictions on DeepSeek often focused on installing the app or entering government information into a public chatbot. Order 2026-01 turns the issue into software provenance. Agencies must determine whether a product was developed using a DeepSeek implementation, language that could cover services in which the model is hidden behind a vendor’s interface.
The notice does not spell out a universal technical test for that phrase. Until CISA or DHS publishes more detailed implementation guidance, contractors should document where DeepSeek is used, whether it runs at build time or in production, what data reaches it, and whether the delivered service depends on it. Agencies can then evaluate scope with the FASCSA implementation team instead of relying on a vendor’s informal interpretation.
The order is unlikely to end federal use of inexpensive open-weight models as a category. It does raise the documentation standard for AI systems sold to government. A model bill of materials, deployment-location record, data-flow map and vendor attestation are becoming procurement evidence, not optional architecture notes.
Updated October 19, 2026, with the Federal Register public-inspection notice and the scope of Exclusion and Removal Order 2026-01.
