DHS FASCSA Order 2026-01: DeepSeek Exclusion and Removal Explained

DHS Exclusion and Removal Order #2026-01, published in the Federal Register on 20 October 2026, tells federal civilian agencies to stop buying DeepSeek products and to remove DeepSeek products, and third-party products "developed using DeepSeek implementations", from their IT systems. If you sell software or services to a civilian agency, inventory every DeepSeek app, API call, SDK and model weight in what you deliver now.

The order itself carries an original release date of 24 July 2026. The public notice came almost three months later. That gap, and a scope phrase the order does not define, are the two things most suppliers will get wrong. This guide reads the order line by line, sets out what is settled and what is not, and then walks through a practical inventory of DeepSeek across endpoints, code, model files and cloud accounts, with a read-only script you can run today.

This is a reading of public documents, not legal advice. Contract questions belong with your contracting officer and your counsel.

The short answer

• What it is. An exclusion and removal order issued by DHS under the Federal Acquisition Supply Chain Security Act of 2018 (FASCSA), numbered #2026-01. It names Hangzhou DeepSeek Artificial Intelligence Basic Technology Research Co., Ltd. and its affiliates.
• Who must act. Federal civilian executive branch agencies, except for their national security systems and secure compartmented information systems. The Department of Defense and the intelligence community fall under their own FASCSA officials, not this order.
• What they must do. Exclude DeepSeek, its affiliates and their products from procurements, effective immediately after issuance. Remove DeepSeek products and third-party products and services developed using DeepSeek implementations from agency IT immediately after issuance, or ask CISA for an exception.
• Where suppliers come in. Through the FAR clauses 52.204-29 and 52.204-30, which require offerors and contractors to check SAM.gov for FASCSA orders, make a representation, report covered use within 3 business days, and flow the clause down to subcontractors. A removal order can also reach contractor systems operated on an agency's behalf.
• What to do this week. Find every DeepSeek touchpoint in the products and services you deliver to civilian agencies: hosted API calls, mobile and desktop apps, SDK packages, model weights, fine-tunes whose base model is DeepSeek, and gateways that can route to DeepSeek. Write down what you found and what you changed.

If you need the background on what a FASCSA order is and where suppliers find one, start with our explainer, What is a FASCSA order and how suppliers check for one. This post assumes that background and stays on Order #2026-01.

What happened

The order was signed by the Secretary of Homeland Security, Markwayne Mullin, with a copy to Russell Vought, Director of the Office of Management and Budget. Its header gives an original release date of 24 July 2026. On 20 October 2026, DHS published a notice in the Federal Register (document 2026-21447, 91 FR 66346 to 66350, Docket No. DHS-2026-0628) with a scanned copy of the signed order as an appendix. The notice is signed by James H. Percival II, General Counsel of DHS, and says the Secretary acted "following review of the Federal Acquisition Security Council Recommendation and affiliated evidence."

Timeline

Two notes on that table. The 60-day dates are arithmetic, not dates the order states. And the 22 September date has already passed, which matters if your agency customer reads the clock from July.

What the order says, section by section

The signed order runs four pages. It has a short authority paragraph, then sections headed Background, Summary of Risks from Source, Scope, Required Actions, Exceptions, Interim Cybersecurity Measures, Actions by DHS and its Cybersecurity and Infrastructure Security Agency (CISA), and Additional Information.

Authority

The order cites FASCSA, 41 U.S.C. 1321 to 1328, and the implementing rule at 41 CFR part 201-1. Under 41 U.S.C. 1323(c)(5)(A), the Secretary of Homeland Security reviews recommendations of the Federal Acquisition Security Council (FASC) and may issue exclusion and removal orders for civilian agencies, to the extent those systems are not covered by the Secretary of Defense or the Director of National Intelligence. The order quotes the rule's compliance section, 41 CFR 201-1.304, which says executive agencies "shall comply" with orders issued under 201-1.303. The statute says the same thing in 1323(c)(7).

One part of the statute is worth knowing because it shapes how these orders are written. 41 U.S.C. 1323(f)(2) says nothing in the section authorises an order "based solely on the fact of foreign ownership" of an otherwise qualified source. Order #2026-01 accordingly lists specific risk claims about the products, not only where the company is based.

Who it names

The order names "Hangzhou DeepSeek Artificial Intelligence Basic Technology Research Co., Ltd." and refers to it as DeepSeek. The Federal Register summary uses a shorter form, "Hangzhou DeepSeek Artificial Intelligence Co., Ltd". Treat both as the same named source for search purposes.

Affiliates are in scope. Footnotes 9 and 12 say an individual or business is an affiliate "of DeepSeek AG" if either one controls or can control the other, or a third party controls or can control both, and they point to the FAR definition of "affiliates" in 48 CFR 2.101. That is how the text reads; the footnotes say "DeepSeek AG" while the body names the Hangzhou company. We report it as printed and do not read anything into it. If your supplier map includes any entity that might be an affiliate under the control test, put the question to counsel rather than guessing.

The risk claims

The order's "Summary of Risks from Source" makes these claims, each footnoted in the original. They are the order's statements, attributed to it here:

• DeepSeek's servers are located in the People's Republic of China (PRC), and the order says the PRC legal system permits extensive government access to private company infrastructure.
• For DeepSeek-hosted instances of its models, the order says account creation collects personally identifiable information and "may also track and digitally fingerprint users."
• DeepSeek's most widely used applications work by prompt and response, which the order says may result in the transfer of sensitive data to the PRC if used by US government employees or vendors.
• The order says the models themselves "may contain malware or other security vulnerabilities."
• It cites a February 2025 security research report that found multiple critical vulnerabilities in the DeepSeek iOS app.

The footnotes cite DeepSeek's own privacy policy (archived March 2025), a December 2020 DHS data security business advisory, the April 2025 House Select Committee report, a February 2025 policy center essay and two press or reference articles.

Read the risk list carefully, because it tells you what the order is worried about. Most of it is about data leaving for hosted services and apps. The model weights point is a single sentence. That difference matters later, when we get to self-hosted and fine-tuned models.

Scope

The Scope section directs civilian agencies to:

1. Exclude DeepSeek, DeepSeek-affiliated entities and their products from civilian agency procurements. Footnote 10 adds that this is "To include third party implementations of DeepSeek used to provide products and services" to civilian agencies.
2. Remove products provided by DeepSeek and DeepSeek entities, and "third-party products and services developed using DeepSeek implementations", from civilian agency information technology systems.

Footnotes 11 and 14 say that under 41 U.S.C. 1323(c)(5)(A)(i), orders from the Secretary apply to civilian "information and communications technology" as defined in 41 U.S.C. 1321(5). The rule at 41 CFR 201-1.101 spells that out as information technology under 40 U.S.C. 11101, information systems under 44 U.S.C. 3502, and telecommunications equipment and services.

Required actions

All civilian agencies are required to:

1. Exclude DeepSeek, its affiliates and their products from procurements "effective immediately after issuance of this Order", including agency-approved product lists, service provider equipment lists, e-commerce markets and other functions that help agencies buy IT hardware, software and services.
2. Remove products provided by DeepSeek, its affiliates, and third-party products and services developed using DeepSeek implementations from agency IT systems "immediately after the issuance of the Order, or seek an Exception."

The word "immediately" appears in both. There is no phased schedule.

Exceptions

Agencies may ask the DHS issuing official for an exception under 41 CFR 201-1.304(b): for the order not to apply to the agency, to certain actions, or for a delay in compliance. Requests must be in writing "within 60 days" of issuance and must include five things, which mirror the rule:

1. Identification of the order.
2. A description of the exception sought, and which provisions it covers if it is partial.
3. The name or a description sufficient to identify the covered article, or the product or service, that the exception concerns.
4. A compelling justification, such as impact on mission-critical functions, or national interest considerations including national security reviews, investigations or agreements.
5. Any alternative mitigations the agency will take to reduce the risks the order addresses.

The rule adds a sixth item, "any other information requested by the issuing official." CISA reviews requests and gives written approval or disapproval. Requests go to FASCSA.Orders@cisa.dhs.gov.

Note who can ask. The exception path in the order is for executive agencies. A contractor does not file an exception under 201-1.304(b). A contractor that needs relief works through its contracting officer under the waiver and disclosure paragraphs of the FAR clauses, covered below.

Interim measures

Between issuance and full removal, the order "encouraged" agencies to address risk by monitoring traffic in and out of the agency, adding enhanced logging and data exfiltration controls for the relevant systems, and detecting and flagging anomalous activity. These are encouraged, not required, but a supplier that cannot remove a DeepSeek dependency on day one should expect its customer to ask for exactly these controls in the meantime.

What DHS and CISA will do

CISA may give technical help to agencies that lack the internal capability to comply. DHS will review exception requests. The Secretary will review the order within one year and annually after that, as FASCSA requires; the rule at 41 CFR 201-1.303(h) sets the same annual review and 201-1.303(i) lets the official modify or rescind an order, provided a modified order is not broader than before.

How the order reaches suppliers

The order is addressed to agencies. Suppliers feel it through three channels.

Channel 1: the FAR clauses

FAR 52.204-29 is a solicitation provision. By submitting an offer, the offeror represents that it "has conducted a reasonable inquiry" and does not propose to provide or use any covered article, or any product or service from a covered source, prohibited by an applicable FASCSA order in effect on the date the solicitation was issued, unless waived or disclosed. Offerors search SAM.gov for the phrase "FASCSA order" and also read the solicitation for orders not in SAM.

FAR 52.204-30 is the contract clause. Its main duties for contractors, read directly from the eCFR text current to 22 October 2026:

The clause defines "reasonable inquiry" as one "designed to uncover any information in the entity's possession" about covered articles or products from a covered source, and says it does not require an internal or third-party audit. That is a modest bar, but it is a bar. "We did not look" does not meet it. An inventory you can show does.

Channel 2: removal orders and contractor systems

The rule at 41 CFR 201-1.303(e)(2) says a removal order may require removal of a covered article from an agency system, "from an information system operated by a contractor on behalf of an agency", and from other contractor systems to the extent the order applies to them. If you run a hosted system for a civilian agency, assume your environment is in scope of the removal half of this order.

Channel 3: customer pressure

Agencies that must remove "third-party products and services developed using DeepSeek implementations" need to know which of their vendors' products fit that description. Expect questionnaires, contract modifications adding the order, and direct questions from program offices. A short, dated, evidence-backed answer is worth more than a long policy statement.

Is the order in SAM?

We could not confirm from SAM.gov whether Order #2026-01 is listed there; the SAM search page renders in the browser and did not return results to a scripted request, and the regulations.gov docket page refused scripted access. Search SAM.gov for "FASCSA order" yourself and save a dated screenshot of the result. If it is not listed, the clause says the government may identify orders in the solicitation instead, so read your solicitations and modifications too.

The open question: what counts as "developed using DeepSeek implementations"

The order does not define this phrase, and neither does the rule. Footnote 10 adds "third party implementations of DeepSeek used to provide products and services" to civilian agencies, which widens the procurement side but does not define the term either. Below are the cases suppliers keep asking about. For each we say what the text says, and what evidence you should gather whichever way your counsel reads it. We do not say which cases are covered, because the text does not settle that.

The safe operating posture while the text stays open is simple. Know exactly where every DeepSeek artifact sits. Remove what is easy to remove. For anything you keep, write down why, what controls surround it, and who decided. Then ask your contracting officer or FASCSA.Orders@cisa.dhs.gov, and keep their answer with the inventory.

Technical details

This section is the working part of the post: what DeepSeek looks like in an estate, where it hides, and how to find it without downloading anything risky.

DeepSeek artifact types

DeepSeek's docs also note that deepseek-flash is now served by a model called DeepSeek-V4.1-Flash-1017. Model names behind a stable API name change over time, so search for the API name and the base URL, not only for a model version.

The derivative problem in numbers

Hugging Face's public API lets anyone count derivatives by base model. On 25 October 2026 it returned these counts:

These counts only cover models that declare their lineage in metadata. A derivative that omits base_model from its card does not show up, and that is common. The point for an inventory is that a model with a neutral name, published by someone else, may still descend from a DeepSeek release.

Why config files are not enough

You might expect the model's config.json to give its origin away. Sometimes it does: deepseek-ai/DeepSeek-V3 declares architecture DeepseekV3ForCausalLM and model type deepseek_v3, and deepseek-ai/DeepSeek-V4-Pro declares DeepseekV4ForCausalLM and deepseek_v4. But the distilled releases do not. deepseek-ai/DeepSeek-R1-Distill-Qwen-7B declares Qwen2ForCausalLM and model type qwen2, because it is a Qwen-architecture model trained by DeepSeek. Scan only for deepseek in configs and you will miss every distill and every derivative of a distill.

That is why lineage has to come from records, not inference: the model card's base_model field, the repository it was pulled from, and a file hash you recorded when it entered your estate.

Recording lineage in an AI bill of materials

Both major SBOM formats can carry this. In CycloneDX 1.6, a model is a component of type machine-learning-model; its modelCard holds modelParameters (with approach, task, architectureFamily, modelArchitecture, datasets, inputs and outputs), quantitativeAnalysis and considerations; and the component's pedigree carries ancestors, descendants and variants, which is where a base model belongs. In SPDX 3.0.1, the AI profile's AIPackage class has properties including typeOfModel, informationAboutTraining, limitation, safetyRiskAssessment and useSensitivePersonalInformation, and the core relationship types include ancestorOf, descendantOf, trainedOn and testedOn.

A minimal CycloneDX entry for the fine-tune in our fixture below would look like this:

{
  "type": "machine-learning-model",
  "name": "local-reasoner",
  "version": "2026.10.1",
  "hashes": [{ "alg": "SHA-256", "content": "<sha256 of the weight file>" }],
  "modelCard": {
    "modelParameters": {
      "task": "text-generation",
      "architectureFamily": "qwen2"
    }
  },
  "pedigree": {
    "ancestors": [
      {
        "type": "machine-learning-model",
        "name": "deepseek-ai/DeepSeek-R1-Distill-Qwen-7B",
        "publisher": "deepseek-ai",
        "externalReferences": [
          { "type": "distribution", "url": "https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Qwen-7B" }
        ]
      }
    ]
  }
}

With that entry in place, "does anything we ship descend from DeepSeek" becomes a query rather than a meeting. For a fuller treatment of both formats, see our CycloneDX ML-BOM 1.7 implementation guide and the SPDX 3.0 AI profile guide.

How to inventory DeepSeek across your estate

Work through five surfaces. None of these steps downloads weights or calls DeepSeek.

1. Code and configuration

Here is a read-only Python script that walks a source tree and reports DeepSeek references by kind. It reads text files only, skips files over 2 MB, never opens weight files (it only notes their names), and makes no network calls.

#!/usr/bin/env python3
"""Read-only inventory of DeepSeek references in a source tree.

Usage: python3 deepseek_inventory.py PATH [--json]
Reads text files only, never opens weight files, never makes network calls.
"""
import json, os, re, sys

SKIP_DIRS = {".git", "node_modules", ".venv", "venv", "__pycache__", "dist", "build"}
WEIGHT_EXT = (".gguf", ".safetensors", ".bin", ".pt", ".pth", ".onnx")
MAX_BYTES = 2_000_000

RULES = [
    ("api-endpoint", re.compile(r"(?:chat|api|platform)\.deepseek\.com[\w/.-]*", re.I)),
    ("api-key-var",  re.compile(r"\bDEEPSEEK_[A-Z_]*(?:KEY|URL|BASE)[A-Z_]*\b")),
    ("hosted-model", re.compile(r"(?<![\w.-])(?:deepseek/)?deepseek-(?:chat|reasoner|flash|v4-pro|v4-flash[\w-]*)\b", re.I)),
    ("hf-repo",      re.compile(r"\bdeepseek-ai/[\w.-]+", re.I)),
    ("ollama-tag",   re.compile(r"\b(?:deepseek-[\w.]+|r1-1776|deepscaler):[\w.-]+", re.I)),
    ("base-model",   re.compile(r"^\s*-?\s*base_model\s*:.*deepseek", re.I)),
    ("model-config", re.compile(r"\"(?:model_type|architectures)\"\s*:\s*\[?\s*\"deepseek", re.I)),
    ("sdk-package",  re.compile(r"(?:@ai-sdk/deepseek|langchain[-_]deepseek)", re.I)),
]

def scan(root):
    hits = []
    for dirpath, dirnames, filenames in os.walk(root):
        dirnames[:] = [d for d in dirnames if d not in SKIP_DIRS]
        for name in filenames:
            path = os.path.join(dirpath, name)
            rel = os.path.relpath(path, root)
            if name.lower().endswith(WEIGHT_EXT):
                if "deepseek" in name.lower():
                    hits.append({"kind": "weight-file", "file": rel, "line": 0,
                                 "match": f"{name} ({os.path.getsize(path)} bytes)"})
                continue
            try:
                if os.path.getsize(path) > MAX_BYTES:
                    continue
                with open(path, encoding="utf-8", errors="strict") as fh:
                    lines = fh.readlines()
            except (UnicodeDecodeError, OSError):
                continue
            for n, line in enumerate(lines, 1):
                for kind, rx in RULES:
                    m = rx.search(line)
                    if m:
                        hits.append({"kind": kind, "file": rel, "line": n, "match": m.group(0).strip()})
    return sorted(hits, key=lambda h: (h["file"], h["line"]))

if __name__ == "__main__":
    if len(sys.argv) < 2:
        sys.exit(__doc__)
    results = scan(sys.argv[1])
    if "--json" in sys.argv:
        print(json.dumps(results, indent=2))
    else:
        for h in results:
            print(f"{h['kind']:<13} {h['file']}:{h['line']}  {h['match']}")
        files = len({h['file'] for h in results})
        print(f"\n{len(results)} references in {files} files")

We ran it against a small fixture folder built to look like a typical mixed estate: a Python service that calls the hosted API through the OpenAI SDK, a web widget with the AI SDK DeepSeek provider, a Compose file that pulls an Ollama tag, a LiteLLM routing config, a placeholder GGUF file, and an internal fine-tune whose card names a DeepSeek distill as its base model. The fixture holds eight files:

fixture/deploy/litellm.yaml
fixture/deploy/ollama-compose.yaml
fixture/ml/models/deepseek-r1-7b-q4_k_m.gguf
fixture/ml/models/local-reasoner/README.md
fixture/ml/models/local-reasoner/config.json
fixture/svc-chat/app/llm.py
fixture/svc-chat/requirements.txt
fixture/web/package.json

This is the real output:

$ python3 -I deepseek_inventory.py fixture
hosted-model  deploy/litellm.yaml:4  deepseek/deepseek-reasoner
api-endpoint  deploy/litellm.yaml:5  api.deepseek.com
ollama-tag    deploy/ollama-compose.yaml:4  deepseek-r1:7b
weight-file   ml/models/deepseek-r1-7b-q4_k_m.gguf:0  deepseek-r1-7b-q4_k_m.gguf (4 bytes)
hf-repo       ml/models/local-reasoner/README.md:3  deepseek-ai/DeepSeek-R1-Distill-Qwen-7B
api-key-var   svc-chat/app/llm.py:5  DEEPSEEK_API_KEY
api-endpoint  svc-chat/app/llm.py:6  api.deepseek.com
hosted-model  svc-chat/app/llm.py:8  deepseek-flash
sdk-package   svc-chat/requirements.txt:2  langchain-deepseek
sdk-package   web/package.json:5  @ai-sdk/deepseek

10 references in 7 files

Read the output for what it does not say as well as what it does. The fine-tune's config.json declares Qwen2ForCausalLM, so it produced no hit. The model was caught only because its README kept the base_model line. Strip that line and the script would miss it. That is the derivative problem from the previous section in miniature, and it is why the script is a starting point, not proof of absence.

Our first version also missed the LiteLLM line, because the model string deepseek/deepseek-reasoner was not wrapped in quotes. We fixed the pattern and reran. Expect to tune the patterns to your own codebase in the same way, and keep the version you used with the results.

Run it across every repository that builds something a civilian agency receives:

for repo in ~/src/*/; do
  echo "== $repo"
  python3 -I deepseek_inventory.py "$repo" --json > "inventory-$(basename "$repo").json"
done

Then check lockfiles directly, since transitive packages do not appear in top-level manifests:

# npm, pnpm and yarn lockfiles
grep -rn --include='package-lock.json' --include='pnpm-lock.yaml' --include='yarn.lock' \
  -e '@ai-sdk/deepseek' -e 'deepseek' .

# Python lockfiles and requirements
grep -rn --include='*.lock' --include='requirements*.txt' --include='pyproject.toml' \
  -i -e 'deepseek' .

2. Model files and registries

Search storage for weight files and model cards, by name and by card metadata:

# Weight files with DeepSeek in the name (names only, files are not opened)
find / -xdev \( -iname '*deepseek*.gguf' -o -iname '*deepseek*.safetensors' \) 2>/dev/null

# Local Hugging Face cache entries
ls ~/.cache/huggingface/hub 2>/dev/null | grep -i deepseek

# Model cards anywhere in a model store that declare a DeepSeek base model
grep -rl --include='README.md' -i -E 'base_model:.*deepseek|deepseek-ai/' /srv/models

# Local runner inventory on each host that runs Ollama
ollama list | grep -i -E 'deepseek|r1-1776|deepscaler'

For each model found, record the file's SHA-256, where it came from, and its declared base model. If a model has no card, record that too; "lineage unknown" is a finding in its own right.

To check a Hugging Face model's declared lineage without downloading it, read its metadata from the public API:

curl -s https://huggingface.co/api/models/deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \
  | python3 -c 'import json,sys; d=json.load(sys.stdin); print(d["config"]["architectures"], d.get("cardData",{}).get("base_model"))'

# List public models that declare a DeepSeek model as their base
curl -s "https://huggingface.co/api/models?filter=base_model:finetune:deepseek-ai/DeepSeek-R1&limit=1000" \
  | python3 -c 'import json,sys; [print(m["id"]) for m in json.load(sys.stdin)]'

Compare the second list with the model IDs in your own registry. A match is a lineage you now know about.

3. Container images

Images often bake in weights or pull them at start. Search image filesystems and entrypoints:

# Entrypoints and env that pull or point at DeepSeek
docker image inspect myorg/inference:1.4.2 \
  --format '{{json .Config.Entrypoint}} {{json .Config.Cmd}} {{json .Config.Env}}' \
  | grep -i deepseek

# Files inside the image with DeepSeek in the path
docker create --name inspect-tmp myorg/inference:1.4.2 >/dev/null
docker export inspect-tmp | tar -t | grep -i deepseek
docker rm inspect-tmp >/dev/null

An SBOM of each image records the packages; pair it with the file listing to catch weights that no package manager knows about.

4. Network egress

The order's interim measures are about traffic, logging and exfiltration controls, so egress evidence is the most useful thing you can hand an agency customer. Query DNS and proxy logs for DeepSeek domains over at least the last 90 days:

api.deepseek.com
chat.deepseek.com
platform.deepseek.com
cdn.deepseek.com

Zero hits across a known window is strong evidence for your representation. Hits tell you which hosts and services still call out, which you then match against the code inventory. Once remediation is done, add a deny rule for these domains on egress from systems that serve civilian agencies, and keep logging the denials.

5. Endpoints, SaaS and developer tools

• Mobile and desktop. Pull the app inventory from your MDM for DeepSeek's iOS and Android apps on any device used in agency work.
• Browsers. Check managed browser policies and logs for the web chat domain.
• Coding assistants and agents. DeepSeek's docs list integrations with many coding assistants and agent tools, where DeepSeek becomes the backend by changing a base URL. Check the settings files of the tools your developers use for a DeepSeek base URL or key.
• Model gateways and aggregators. If your products route through any multi-model gateway, export its list of enabled models and its routing logs. A DeepSeek model that is selectable but unused still needs a decision.
• Cloud AI services. Check your cloud accounts' managed model catalogues and deployments for DeepSeek models enabled or deployed in the regions that serve agency workloads.

For a broader method on finding model use that nobody registered, see discovering shadow AI models in production.

What to do now

A practical sequence for a supplier to civilian agencies:

1. Search SAM.gov for "FASCSA order" and save a dated record of the result. Read your open solicitations and recent modifications for the order.
2. Name an owner. One person owns the answer to "do we use DeepSeek" and signs the inventory.
3. Scope the inventory to every product, service and subcontracted service delivered to a civilian agency, plus systems you operate on an agency's behalf.
4. Run the five surfaces above: code and config, models, images, egress, endpoints and tools.
5. Classify each hit with the case table from the open-question section: plain DeepSeek product, hosted API, gateway, self-hosted weights, fine-tune, distill, developer tool, subcontractor.
6. Remove what is easy. Hosted API calls and SDK packages usually have drop-in alternatives because DeepSeek's API is OpenAI and Anthropic format compatible; switching providers is often a base URL, a key and a model name.
7. For anything you keep, document why. Note the controls around it (no egress, logging, hashes) and get a written view from your contracting officer.
8. Report if you must. If you find covered use under a contract that carries 52.204-30 with the order applied, the clock is 3 business days for the first report and 10 more for the follow-up.
9. Flow down. Ask subcontractors for their own inventory and representation, and record their answers.
10. Keep it current. Rerun the inventory on every release and check SAM.gov at least every three months, as the clause requires.

Where Safeguard fits

Safeguard does not decide whether something is covered by a FASCSA order, and it does not guarantee compliance. It can help with the inventory that a reasonable inquiry rests on.

• SBOM generation (GA). safeguard scan --dir ., --image <name> and --sbom <file> produce dependency inventories for repositories, container images and existing SBOM files, with results as JSON under ./output. The platform shows which projects contain a given component and version, so a question like "where is langchain-deepseek or @ai-sdk/deepseek" is a search, not a project-by-project hunt.
• Model and agent scanning (GA). Safeguard scans model artifacts pulled from Hugging Face or supplied directly, plus agent configurations and skills, as assets in their own right.
• Asset discovery with policies and gates (GA). Discovered assets, including AI models, can be held to policies and gates that block, warn, notify or require approval in CI.
• AI-BOM discovery (Early Access). Inventories AI assets across code, cloud and SaaS and emits CycloneDX ML-BOM and the SPDX AI profile. It is early access, so confirm coverage for your stack before you plan around it.

Two honest limits. Safeguard's inventory, like the script above, depends on what the artifacts declare; a derivative model that hides its base model will not announce itself to any tool. And consumer app use on phones and laptops lives in your MDM and network logs, not in a code scanner.

If you serve civilian agencies, treat every model you can select in any gateway as part of this inventory.

Common mistakes

Reading the clock from the wrong date. The order says 24 July 2026 at the top and was published on 20 October 2026. It also says "immediately" for both exclusion and removal. Do not assume you have until a date in December. Ask the contracting officer which date your customer is using, and act now either way.

Assuming self-hosting makes it a non-issue. The order's risk summary focuses on hosted services and apps, but its scope language covers "third party implementations of DeepSeek". The text does not exempt self-hosted weights. Neither does it clearly include them. Inventory them and document your controls.

Searching configs only for "deepseek". Distilled DeepSeek releases declare Qwen or Llama architectures. Their derivatives may not mention DeepSeek anywhere except a model card field that a re-uploader may have deleted.

Forgetting the gateway. Many teams route all model calls through one service. If that service can reach DeepSeek, it is part of the answer even if no product code names DeepSeek.

Confusing an agency exception with a contractor waiver. Agencies request exceptions from CISA under 41 CFR 201-1.304(b). Contractors disclose and ask through the contracting officer under the FAR clauses. Do not email CISA asking for an exception on your own behalf and assume you are covered.

Ignoring subcontractors. 52.204-30(e) flows down to every subcontract, including commercial products and services. Your representation covers what your suppliers put into your delivery.

Treating "no hits" as proof. A clean scan proves only that the patterns did not match. Pair it with egress logs and a statement of what you searched, when, and with which version of the tooling.

Overclaiming in either direction. Do not tell a customer "we are certified DeepSeek-free". Tell them what you inventoried, what you found, what you changed, and what remains under review.

Open questions

• Which date starts the 60-day exception window, 24 July or 20 October? The order says "within 60 days of the issuance of this order" and does not say which.
• What "developed using DeepSeek implementations" covers, especially for fine-tunes, distills and self-hosted open weights.
• Whether and when the order appears in SAM.gov, which drives how 52.204-29 and 52.204-30 pick it up for new solicitations.
• The "DeepSeek AG" wording in the affiliate footnotes, where the body names the Hangzhou company.
• How agencies will treat developer tools, where DeepSeek was used to help write code but is not part of the delivered product.

Each of these is a question for your contracting officer, your counsel or FASCSA.Orders@cisa.dhs.gov. Keep their answers with your inventory.

FAQ

Does Order #2026-01 apply to the Department of Defense?

No. It applies to federal civilian executive branch agencies, excluding their national security systems and secure compartmented information systems. Under 41 U.S.C. 1323(c)(5)(A), DoD and national security systems fall to the Secretary of Defense, and the intelligence community and compartmented systems to the Director of National Intelligence. FAR 52.204-30 says DoD contracting offices apply DoD FASCSA orders.

I am a contractor. Does the order bind me directly?

The order is addressed to agencies. It reaches contractors through the FAR clauses when the order applies to a solicitation or contract, and through the rule's provision that a removal order can cover systems a contractor operates on an agency's behalf. In practice, if you deliver to a civilian agency, plan as if it applies.

Is the order the same as a ban on the DeepSeek app on government phones?

It is broader. The app is covered, but so are DeepSeek products generally, affiliates, and third-party products and services developed using DeepSeek implementations. It also covers procurement, not only use.

Can my agency customer keep using DeepSeek while it asks for an exception?

The order says to remove immediately or seek an exception, and encourages interim measures such as traffic monitoring, enhanced logging and exfiltration controls in the meantime. Whether a pending request allows continued use is for the agency and CISA. As a supplier, help your customer by documenting the controls in place.

What does a "reasonable inquiry" require from me?

FAR 52.204-30 defines it as an inquiry designed to uncover information in your possession about covered articles or products from a covered source, and says it does not require an internal or third-party audit. A documented inventory of code, models, images, egress and endpoints meets the spirit of that well.

How fast do I have to report covered use?

Under 52.204-30(c)(4), within 3 business days of identifying it, with a follow-up within 10 business days of that first report. Non-DoD contractors report to the contracting officer.

Does using the OpenAI SDK with DeepSeek's base URL count as using DeepSeek?

The SDK itself is not a DeepSeek product, but the service it calls is. DeepSeek's docs show exactly this pattern: install the OpenAI SDK and set base_url to https://api.deepseek.com. Search for the base URL and the API key variable, not only for package names.

We fine-tuned a DeepSeek distill on our own data and host it ourselves. Are we covered?

The order does not say. Record the base model, the training data, the hosting location, file hashes and egress controls, then ask your contracting officer. If replacing the model is cheap, replacing it may be faster than resolving the question.

Is the DeepSeek Hugging Face organisation the only source of DeepSeek weights?

No. Third parties publish quantized copies, adapters, merges and fine-tunes, and local runners package their own builds. That is why lineage records matter more than the publisher's name.

Will the order change?

The Secretary must review it within one year and annually after that, and the rule allows modification or rescission, provided a modified order is not broader than the original. Recheck SAM.gov and the Federal Register on a schedule.

Fix it without waiting for upstream

Most of this post is about removing a dependency, not patching one. But the same inventory that finds DeepSeek also finds the vulnerable packages sitting next to it, and the habits below are how teams keep that second list short.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows DeepSeek or a FASCSA order. Each is a real Safeguard session, and each intro says how the same flow applies to the inventory and removal work in this guide.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For this order, you would open the CLI in the service that calls DeepSeek's hosted API and ask it to replace the langchain-deepseek dependency and the api.deepseek.com base URL with your approved provider, approving each edit and test run.

Click through it at your own pace, or open it full screen.

This session sets up the Safeguard runner on your own machine, approves it with its device code, and scans from the terminal. That is the shape of the first inventory pass here: run the scan locally against each repository and image that ships to a civilian agency, then search the results for DeepSeek packages alongside the script output.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Removing a DeepSeek integration from a monorepo fits that shape: pick the folder, ask for the provider swap and the lockfile update, and approve or deny each edit as it comes.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs. For related reading, see software supply chain compliance for federal contractors, AI-BOMs explained and our earlier post on the 2025 DeepSeek ClickHouse exposure.

Quick check

Sources

• Federal Register API record, document 2026-21447
• Federal Register, 91 FR 66346 to 66350, Notice of Order Regarding Exclusion and Removal of DeepSeek Products (govinfo PDF, includes the signed order)
• Federal Register document page, 2026-21447
• 41 U.S.C. 1323, Functions of the Federal Acquisition Security Council (govinfo)
• 41 CFR part 201-1, Federal Acquisition Supply Chain Security (eCFR)
• 48 CFR 52.204-29, FASCSA Orders, Representation and Disclosures (eCFR)
• 48 CFR 52.204-30, FASCSA Orders, Prohibition (eCFR)
• 48 CFR 2.101, Definitions, "Affiliates" (eCFR)
• H.R. 1121, No DeepSeek on Government Devices Act, introduced 7 Feb 2025 (govinfo)
• House Select Committee on the CCP, DeepSeek report cited in the order (PDF)
• DeepSeek API Docs, Your First API Call
• Hugging Face API, models by author deepseek-ai
• Hugging Face API, DeepSeek-R1-Distill-Qwen-7B model metadata
• Ollama library, deepseek-r1 tags
• PyPI, langchain-deepseek
• npm, @ai-sdk/deepseek
• CycloneDX 1.6 JSON schema
• SPDX 3.0.1 AI profile, AIPackage class
• SPDX 3.0.1 RelationshipType vocabulary

Last reviewed: 25 October 2026. This is a reading of public documents, not legal advice; check SAM.gov, the Federal Register and your contracting officer for the latest status.