Counterfeit Electronic Parts and How an HBOM Helps

A counterfeit electronic part is a chip, discrete component or circuit assembly knowingly misrepresented as an authentic, unmodified part from the original manufacturer, including used parts sold as new and parts with a false grade, lot number or date code. Counterfeits usually enter through sources outside authorized distribution, especially when a part is obsolete or scarce. A hardware bill of materials (HBOM) does not detect a fake, but it records who supplied each part, which lot and date code it carried and where it went, so when a suspect lot is reported you can find and quarantine every affected assembly.

Prevention lives in purchasing rules, authorized sources and inspection. Containment lives in records. This post covers both: the US definitions, what GAO found, what DFARS requires, the SAE standards AS5553, AS6081 and AS6171, and which HBOM fields turn a supplier alert into a list of serial numbers. It builds on our posts on HBOM vs SBOM and hardware and firmware inventory from chips to boards. Counterfeiting methods are described only at the level public reports and regulations describe them, so buyers can recognise risk.

Key takeaways

• The legal definition is about misrepresentation. DFARS 252.246-7007 counts used parts sold as new, and false grade, serial number, lot number, date code or performance data, as unauthorized substitution.
• "Suspect counterfeit" is a lower bar that triggers quarantine and reporting: credible evidence giving reasonable doubt of authenticity.
• GAO bought 16 parts online and none were legitimate. In GAO-12-375 (21 February 2012), all 12 tested parts were suspect counterfeit.
• DFARS sets a source hierarchy and requires traceability from the original manufacturer, or documented inspection and testing where traceability cannot be shown.
• SAE splits the work by role. AS5553 for organizations that buy and integrate parts, AS6081 for independent distributors, AS6171 for test methods.
• An HBOM is the containment tool, if it is written at receiving. CISA's HBOM framework has supplier, manufacturer, part number, location and lot or date code fields; CycloneDX adds lot numbers, production timestamps and a pedigree model.

Timeline: how counterfeit part controls developed

What counts as a counterfeit electronic part?

DFARS 252.246-7007 defines a counterfeit electronic part as "an unlawful or unauthorized reproduction, substitution, or alteration" knowingly misrepresented as an authentic, unmodified part from the original manufacturer or a source it has authorized in writing. Unauthorized substitution explicitly includes used parts represented as new and false identification of grade, serial number, lot number, date code or performance characteristics. Every item in that list is a field an HBOM can hold.

An electronic part is an integrated circuit, a discrete component such as a transistor, capacitor, resistor or diode, or a circuit assembly. A counterfeit capacitor on a power rail counts.

FAR 52.246-26 applies the same structure to items in general across federal contracts. 18 U.S.C. 2320 is the criminal side: a "counterfeit military good or service" uses a counterfeit mark and is either falsely labelled as meeting military specifications or intended for military or national security use. For an individual, a first offence involving such goods carries up to $5,000,000 in fines, up to 20 years in prison, or both.

Use "suspect counterfeit" in tickets and records until a determination is made. SAE AS5553E notes that it does not make a legal determination of fraud, and neither should your quality database.

Why counterfeit parts are a security problem

Most counterfeits are made for profit, not sabotage. They still threaten availability, integrity and firmware trust.

NIST SP 800-161 Rev 1 includes a scenario called "Telecommunications Counterfeits." A system needs an element the original manufacturer no longer makes, the integrator turns to secondary market suppliers, and the counterfeits look identical but use lower quality materials. In NIST's numbers, up to 200 counterfeits could be installed before the first failure, adding about $160,000 over ten years, before counting outages against a 99.9 percent uptime requirement.

The SAE AS6171 summary notes its tests "may also detect occurrences of malicious tampering," though the standard is not designed for that. And many parts carry firmware, as our post on why firmware below the OS goes unpatched explains. A relabelled programmable part may not run what its label implies.

NIST's control SR-11, Component Authenticity, asks for anti-counterfeit policy built with acquisition, IT, security and legal input, reporting through channels such as GIDEP, and qualified bidders or manufacturers lists so authorized suppliers are used wherever possible. Its enhancements add anti-counterfeit training, configuration control for service and repair, and anti-counterfeit scanning for critical components at a minimum.

How do counterfeit and recycled chips enter supply chains?

The public record describes a few entry routes, summarized here so buyers can recognise the conditions.

Obsolescence and shortages. Long lived defense, industrial, medical and telecom systems outlast their parts. When the manufacturer stops production or lead times stretch, buyers turn to brokers. NIST's scenario starts there, DFARS 252.246-7007 lists control of obsolete parts as a required system area, and GAO-12-375 deliberately ordered obsolete and rare part numbers.

Used parts sold as new. DFARS names this directly, and 252.246-7008 requires action when a contractor cannot confirm a part is new and not "comingled" with used, refurbished, reclaimed or returned parts. Recycled parts carry unknown handling history and unknown remaining life.

Remarking and false identity. GAO's lab found parts re-marked with authentic part numbers and logos, and date markings altered to look newer, which the original makers confirmed. Grade matters because one function may be sold in commercial, industrial and military temperature ranges at very different prices.

Parts that never existed. GAO also ordered invalid part numbers and vendors still supplied them. Validating the manufacturer part number against the manufacturer's catalogue at receiving catches this.

Clones, rejects and unauthorized production. These fall inside the DFARS phrase "unlawful or unauthorized reproduction, substitution, or alteration." The common thread is a chain the original manufacturer did not authorize, which is what source rules and HBOM supplier fields record.

What GAO found

GAO-10-389 (29 March 2010) examined DOD's knowledge of counterfeits and its prevention processes. It described counterfeits as parts whose sources knowingly misrepresent their identity or pedigree, from aircraft fasteners to missile guidance electronics, and recommended a consistent definition and practices. GAO lists the recommendations as implemented, citing a March 2012 DOD memorandum and DOD Instruction 4140.67 in April 2013.

GAO-12-375 (21 February 2012) is the most cited because GAO acted as a buyer. It requested quotes on two internet purchasing platforms and heard from 396 vendors: 334 in China, 25 in the United States and 37 elsewhere. It bought 16 parts in three groups: obsolete or rare part numbers, authentic part numbers with date codes after production ended, and bogus part numbers. All 16 came from vendors in China under GAO's selection method. All 12 tested parts were suspect counterfeit, with re-marked part numbers and logos, metal compositions short of military standards and altered date markings, found with methods from electron microscopy to X-ray. GAO said none of the 16 were legitimate, stressed that the sample cannot show how widespread counterfeiting is, and made no recommendations.

GAO-16-236 (16 February 2016) looked at reporting. DOD agencies and contractors filed 526 suspect counterfeit reports in GIDEP, the Government-Industry Data Exchange Program, for fiscal years 2011 to 2015, mostly from contractors. GAO found no oversight of agency reporting, no common evidence standard, and frequent restriction of reports to government users. All four recommendations are listed as implemented, including DOD Instruction 5200.49 in August 2022.

The HBOM lesson is in the third report. A GIDEP notice names a part, a manufacturer and often a lot or date code. If your records do not hold those fields for installed parts, the notice matches nothing you own.

What DFARS requires

DFARS 246.870 implements section 818 of the FY2012 NDAA, as amended in FY2015 and FY2016, through two clauses.

252.246-7007: the detection and avoidance system

Contractors subject to the Cost Accounting Standards must maintain an acceptable counterfeit electronic part detection and avoidance system, or risk purchasing system disapproval, withheld payments and unallowable rework costs. The system needs risk based policies covering twelve areas:

Test selection must weigh the probability of receiving a counterfeit, the probability the test catches it, and the consequences if one is installed, such as human safety or mission success. That formula works for any buyer.

252.246-7008: sources of electronic parts

This clause also applies to commercial products bought under FAR part 12. It sets the order of sources:

An authorized supplier has a contractual arrangement with, or express written authority from, the original manufacturer or current design activity to buy, stock, repackage, sell or distribute the part. A contractor approved supplier has no such agreement but has been judged trustworthy by the contractor.

The traceability paragraph is where HBOM thinking enters the regulation. A contractor that is not the original manufacturer or an authorized supplier needs risk based processes to track parts from the original manufacturer to government acceptance, whether discrete or inside an assembly. Where that fails, it must inspect, test and authenticate, and keep documentation for either path under FAR subpart 4.7. Parts from the Federal Supply Schedule, Defense Microelectronics Activity accredited suppliers or government stock remain in scope.

FAR 52.246-26: reporting

FAR 52.246-26 (August 2024 version) requires covered contractors to screen GIDEP reports, notify the contracting officer within 60 days of becoming aware or having reason to suspect a counterfeit, retain the item until disposition instructions arrive, and file a GIDEP report within 60 days, with listed exceptions such as an ongoing criminal investigation. For DOD contracts, good faith reports of counterfeit electronic parts are protected from civil liability. Sixty days is short if step one is working out which products contain the part.

SAE AS5553, AS6081 and AS6171 summarized

SAE's standards are the industry baseline DFARS points to when it mentions established counterfeit prevention standards. The full texts are paid; these summaries come from SAE's public abstract pages.

Two points from the abstracts matter. AS5553 is risk based: mitigation varies "depending on the criticality of the application." And AS6171 is a fallback, to be used when buying from authorized sources, redesigning or having obsolete parts emulated is unavailable or inadequate. Testing is what you do when you could not avoid the risk.

How authorized distribution protects you

Authorized distribution moves the question from "is this part real" to "did it come through a chain the manufacturer stands behind." Practical checks:

1. Confirm authorization with the manufacturer, not the seller, and record the date you checked.
2. Ask for the certificate of conformance and the chain of ownership, tied to a lot.
3. Record source tier on the purchase line, not only in the supplier master. One distributor can be franchised for one manufacturer and a broker for another.
4. Treat exceptions as recorded decisions: who approved, why, and which inspection plan applies.
5. Watch end of life notices. CISA's HBOM framework cites "adherence to PCNs" (product change notices) as an internal compliance use case.

What test and inspection can and cannot prove

Testing reduces risk; it does not create certainty. At a conceptual level, labs combine several kinds of evidence:

Because testing is sample based, the result describes a lot. Your records must know which lot each installed part came from.

How an HBOM helps with counterfeit risk

CISA's HBOM framework (25 September 2023) defines shared fields and use cases. One security category, "Product and Component Level," covers risks from "untrusted, compromised, or counterfeit products and components," and its compliance examples include procuring only from OEM authorized vendors. An HBOM helps in four ways: it shows where non authorized sources were used, records the lot that alerts and lab results refer to, nests parts inside assemblies so one lot expands into a list of affected products, and links each lot to its certificates and test reports.

CISA HBOM fields that matter for counterfeits

The framework has no field for source tier, inspection results or authenticity status. If counterfeit risk matters to you, add them in your own namespace.

CycloneDX fields that matter for counterfeits

CycloneDX models hardware with a device component type. In the 1.6 schema and the official property taxonomy:

• supplier and manufacturer are separate. The schema says the supplier "may often be the manufacturer, but may also be a distributor or repackager," which is the authorized source question.
• cdx:device:lotNumber, cdx:device:prodTimestamp, cdx:device:serialNumber and cdx:device:location record lot, production time, serial and board position.
• pedigree documents components that are "created, distributed, modified, redistributed, combined," with ancestors, descendants, variants and notes, which fits refurbished or reprogrammed parts.
• externalReferences types include certification-report and evidence, to link a lot to its certificate or lab report.

SPDX 3.0.1 can label a package as a device but has no released hardware profile, so these fields are easier in CycloneDX today. Our post on one bill of materials for IoT devices covers the trade offs.

Design HBOM vs as built HBOM

A design HBOM says a board may contain a part. An as built HBOM says units 1042 to 1310 contain lot K1907 bought through an independent distributor. Only the second becomes a recall list.

What an HBOM cannot do

An HBOM records claims. If a remarked part arrives with a false date code and nobody inspects it, the HBOM records the false date code accurately. It does not authenticate parts or replace inspection. Treat it as the index joining purchase orders, inspection results and finished units.

Step by step: record and query counterfeit risk data in a CycloneDX HBOM

This walkthrough records source, lot and inspection data for two parts on a controller board, validates the file, and runs the reverse lookup you need after an alert. Names starting cdx:device: are official CycloneDX properties. Names under example:scrm: are a private namespace for fields CISA and CycloneDX do not define; replace example with your own.

1. Write the as built HBOM for one production lot

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "serialNumber": "urn:uuid:5a1f6a3e-6f0b-4c7a-9b1e-2f6b9d1c0a11",
  "version": 1,
  "metadata": {
    "timestamp": "2026-10-23T09:00:00Z",
    "component": {
      "type": "device",
      "bom-ref": "board-ctl-200-rev-c",
      "name": "CTL-200 controller board",
      "version": "rev C",
      "manufacturer": { "name": "Example Devices Inc" },
      "properties": [
        { "name": "example:scrm:unitSerialRange", "value": "CTL200-1042..CTL200-1310" }
      ]
    }
  },
  "components": [
    {
      "type": "device",
      "bom-ref": "u7-mcu",
      "name": "Microcontroller",
      "manufacturer": { "name": "Example Semiconductor" },
      "supplier": { "name": "Example Authorized Distributor" },
      "properties": [
        { "name": "cdx:device:location", "value": "U7" },
        { "name": "cdx:device:lotNumber", "value": "L2318A" },
        { "name": "example:scrm:manufacturerPartNumber", "value": "EXM-MCU-4410-I" },
        { "name": "example:scrm:dateCode", "value": "2318" },
        { "name": "example:scrm:sourceTier", "value": "authorized" },
        { "name": "example:scrm:authenticityStatus", "value": "accepted" }
      ],
      "externalReferences": [
        { "type": "certification-report", "url": "https://records.example.com/coc/L2318A.pdf" }
      ]
    },
    {
      "type": "device",
      "bom-ref": "u12-ldo",
      "name": "Voltage regulator",
      "manufacturer": { "name": "Example Analog" },
      "supplier": { "name": "Example Independent Distributor" },
      "properties": [
        { "name": "cdx:device:location", "value": "U12" },
        { "name": "cdx:device:lotNumber", "value": "K1907" },
        { "name": "example:scrm:manufacturerPartNumber", "value": "EXA-LDO-33-M" },
        { "name": "example:scrm:dateCode", "value": "1907" },
        { "name": "example:scrm:sourceTier", "value": "contractor-approved" },
        { "name": "example:scrm:obsolete", "value": "true" },
        { "name": "example:scrm:authenticityStatus", "value": "accepted-after-test" },
        { "name": "example:scrm:exceptionApprovedBy", "value": "QA-2026-117" }
      ],
      "externalReferences": [
        { "type": "evidence", "url": "https://records.example.com/lab/K1907-report.pdf" }
      ]
    }
  ],
  "dependencies": [
    { "ref": "board-ctl-200-rev-c", "dependsOn": ["u7-mcu", "u12-ldo"] }
  ]
}

The regulator came from a contractor approved source because it is obsolete, the exception has an approval reference, and the lab report is linked. That is the record DFARS 7008 expects a contractor to produce.

2. Validate the structure and your required fields

Install the official CycloneDX CLI from its GitHub releases and validate against the 1.6 schema, then check that every device has a lot number and source tier:

cyclonedx validate --input-file ctl-200-lot-0914.cdx.json --input-format json --input-version v1_6 --fail-on-errors

jq -r '.components[]
  | select(.type == "device")
  | select(([.properties[]?.name] | index("cdx:device:lotNumber") | not)
        or ([.properties[]?.name] | index("example:scrm:sourceTier") | not))
  | "missing lot or source tier: \(.["bom-ref"])"' ctl-200-lot-0914.cdx.json

Validation proves structure, not facts.

3. List every part not bought from an authorized source

jq -r '.components[]
  | {ref: .["bom-ref"], supplier: .supplier.name,
     tier: ([.properties[]? | select(.name == "example:scrm:sourceTier") | .value][0])}
  | select(.tier != "authorized")
  | "\(.ref)\t\(.supplier)\t\(.tier)"' ctl-200-lot-0914.cdx.json

Each result should have an exception approval and an inspection record before an audit.

4. Reverse lookup after an alert names a lot

Suppose a GIDEP report or supplier notice names lot K1907. Search every stored HBOM:

for f in hboms/*.cdx.json; do
  jq -r --arg lot "K1907" '
    . as $bom
    | .components[]
    | select(any(.properties[]?; .name == "cdx:device:lotNumber" and .value == $lot))
    | [$bom.metadata.component.name,
       ($bom.metadata.component.properties[]? | select(.name == "example:scrm:unitSerialRange") | .value),
       (.properties[]? | select(.name == "cdx:device:location") | .value)]
    | @tsv' "$f"
done

The output gives products, unit ranges and board positions for the FAR 52.246-26 clock. Then quarantine remaining stock of the lot, notify customers as contracts require, and set example:scrm:authenticityStatus to suspect on matching records. If the product ships firmware, link its SBOM from the device record, as in our HBOM vs SBOM post, so hardware alerts and firmware advisories are answered from one inventory, the same pattern as finding affected products fast during an SBOM incident.

Where Safeguard fits, honestly

Safeguard does not generate HBOMs, authenticate parts, inspect components or detect counterfeit hardware, and it is not a procurement or quality system. The receiving records, lab results and queries above belong in your manufacturing, quality and asset systems.

The overlap is the software that rides on the hardware. Boards ship with bootloaders, BMC images and embedded Linux builds full of open source components. Safeguard analyses SBOMs in CycloneDX and SPDX, including ones a hardware vendor supplies (safeguard scan --sbom vendor-firmware-sbom.json), matches declared components against vulnerability databases, shows which of your projects and products contain a given component and version, and accepts CSAF and VEX uploads to record vendor "not affected" statements. Its third party risk module can request SBOMs from suppliers and track responses. All of this depends on suppliers declaring components; Safeguard does not discover what is inside a firmware binary on its own.

Common mistakes

• Writing the HBOM from the design, not from receiving. Counterfeit response needs the lot, date code and supplier of parts actually installed.
• Recording supplier status only in the supplier master. Record source tier per purchase line and per lot.
• Treating a passed test as proof. Tests are sample based. Traceability first, testing as the fallback, as AS6171 frames it.
• Returning suspect parts to the seller. DFARS 252.246-7007 forbids returning them to the supply chain until authenticity is determined; FAR 52.246-26 requires you to hold them for disposition instructions.
• Ignoring spares and field repairs. NIST SR-11(2) calls for configuration control for component service and repair.
• Screening alerts without lot level records. Screening is required by DFARS 7007 and FAR 52.246-26, and it is useless if alerts cannot be matched.
• Calling parts "counterfeit" before a determination. Use "suspect counterfeit," and keep quality nonconformances separate.
• Planning for obsolescence at the last time buy. Track product change notices and decide on lifetime buys or redesigns before brokers are the only option.

FAQ

What is a counterfeit electronic part?

Under DFARS 252.246-7007, an unlawful or unauthorized reproduction, substitution or alteration knowingly misrepresented as an authentic, unmodified part from the original manufacturer or its authorized source. Used parts sold as new, and false grade, lot number or date code, count as substitution.

What is the difference between a counterfeit and a suspect counterfeit part?

A suspect counterfeit part is one where credible evidence, such as inspection or testing, gives reasonable doubt of authenticity. That is enough to trigger quarantine and reporting; a counterfeit determination requires more.

How do counterfeit chips get into the supply chain?

Mostly through purchases outside authorized distribution when parts are obsolete or scarce. GAO-12-375 found re-marked parts, altered date codes and vendors willing to supply nonexistent part numbers. DFARS also names used parts sold as new and comingled stock.

What does DFARS 252.246-7008 require?

Buy from original manufacturers, their authorized suppliers or suppliers buying only from them first; use contractor approved suppliers only when that fails; and for any other source, notify the contracting officer and inspect, test and authenticate. It also requires traceability or documented testing.

What is the difference between AS5553, AS6081 and AS6171?

AS5553 is for organizations that buy and integrate EEE parts. AS6081 is for independent distributors. AS6171 standardizes inspection and test methods for suspect counterfeits when parts lack pedigree to the original manufacturer.

Can an HBOM detect counterfeit parts?

No. Detection comes from authorized sourcing, inspection and testing. An HBOM provides traceability: when a lot is reported as suspect, it tells you which products and units contain it.

Which HBOM fields help with counterfeit risk?

In CISA's framework: COMP_SUPPLIER, COMP_MANUFACTURER, COMP_MANUFACTURER_PN, COMP_DATECODE and the manufacturing and assembly locations. In CycloneDX: separate supplier and manufacturer, cdx:device:lotNumber, cdx:device:prodTimestamp, serials, pedigree and evidence links. Add your own source tier and authenticity status fields.

How long do I have to report a counterfeit part to GIDEP?

Under FAR 52.246-26, covered contractors notify the contracting officer and file a GIDEP report within 60 days of becoming aware or having reason to suspect, with listed exceptions.

Do these rules apply outside defense contracting?

The clauses bind contractors and the subcontractors they flow down to. The practices, authorized sourcing, risk based inspection, lot level traceability and alert screening, suit any maker of long lived equipment, and NIST SP 800-161 Rev 1 recommends anti-counterfeit controls generally.

Fix it without waiting for upstream

Counterfeit parts are a hardware problem, and nothing in this section touches parts, lots or inspection. The fit is indirect: the boards in this post run firmware, bootloaders and management software built from open source components, and your HBOM tooling has dependencies of its own, so keeping that software current is the part of the device supply chain you can fix with a pull request.

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 help

None of these demos inspects hardware or authenticates parts. They show the software side of a device program.

The first demo is a real terminal session with the Safeguard CLI. It reads a vulnerability finding and its advisory, asks before each command, upgrades a dependency, runs the tests with your approval and pushes nothing. The same flow applies to the scripts that store and query your as built HBOMs, and to the bootloader or embedded Linux repositories behind your board firmware.

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

The second demo sets up the local runner on your own machine, approves it with a device code and runs scans from the terminal. That suits a manufacturing or quality network where records stay on site and you want to scan a supplier's firmware SBOM without sending it elsewhere.

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

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. You can then ask which of your projects and products contain a software component named in a firmware advisory, provided the supplier's SBOM is in your Safeguard inventory. Hardware lot lookups still come from your own HBOM store.

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

To try it on your own projects, download Safeguard at safeguard.sh/download and read the CLI documentation.

Quick check

Sources

• GAO-12-375, DOD Supply Chain: Suspect Counterfeit Electronic Parts Can Be Found on Internet Purchasing Platforms
• GAO-16-236, Counterfeit Parts: DOD Needs to Improve Reporting and Oversight to Reduce Supply Chain Risk
• GAO-10-389, Defense Supplier Base: DOD Should Leverage Ongoing Initiatives in Developing Its Program to Mitigate Risk of Counterfeit Parts
• DFARS 252.246-7007, Contractor Counterfeit Electronic Part Detection and Avoidance System
• DFARS 252.246-7008, Sources of Electronic Parts
• DFARS Part 246, Quality Assurance (246.870)
• FAR 52.246-26, Reporting Nonconforming Items
• 18 U.S.C. 2320, Trafficking in counterfeit goods or services (Cornell LII)
• SAE AS5553E summary page
• SAE AS5553D summary page
• SAE AS6081A summary page
• SAE AS6171A summary page
• NIST SP 800-161 Rev 1 Update 1, Cybersecurity Supply Chain Risk Management Practices
• NIST SP 800-161 Rev 1 Update 1 PDF
• CISA, Hardware Bill of Materials (HBOM) Framework for Supply Chain Risk Management
• CISA, A Hardware Bill of Materials Framework for Supply Chain Risk Management (PDF)
• CycloneDX 1.6 JSON schema
• CycloneDX property taxonomy, cdx:device namespace
• CycloneDX, Hardware Bill of Materials capability

Last reviewed: 23 October 2026.