CPE vs PURL for Medical Device SBOMs: Which Identifier and When

Every component in your SBOM needs a unique identifier. CPE and PURL are the two that matter. They were built for different purposes, they don't map cleanly to each other, and getting that mapping wrong is a quiet but real way to ship a medical device with blind spots in your postmarket CVE monitoring.

Last reviewed: May 2026 against the FDA February 2026 final guidance, CycloneDX 1.6, SPDX 2.3, and NVD CPE Dictionary practice as of Q2 2026.

At a glance - CPE vs PURL in one paragraph

PURLs identify open-source packages by where you got them - pkg:npm/lodash@4.17.21, pkg:pypi/cryptography@42.0.5, pkg:maven/org.openssl/[email protected]. They're generated automatically by SBOM tooling from package-manager metadata. CPEs identify products by NIST-curated strings - cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*. They're what the NVD attaches CVEs to. The FDA's 2026 guidance and CycloneDX/SPDX both accept PURL and CPE as valid component identifiers. In practice, your build-time SBOM is PURL-heavy and your postmarket vulnerability monitoring is CPE-heavy - and the mapping between them is where most medical device cybersecurity programs leak.

What CPE is

Common Platform Enumeration is a structured naming scheme NIST maintains as the official CPE Dictionary. Every entry is a 13-field colon-delimited string:

cpe:2.3:a:openssl:openssl:3.0.13:*:*:*:*:*:*:*
    │   │ │      │      │      │
    │   │ │      │      │      └─ update / edition / language / sw_edition / target_sw / target_hw / other
    │   │ │      │      └─ version
    │   │ │      └─ product
    │   │ └─ vendor
    │   └─ part: 'a' (application), 'o' (OS), 'h' (hardware)
    └─ CPE 2.3 spec version

Key properties:

• Centralized. A new product needs a CPE entry in the NVD dictionary before CVEs can be attached to it. NIST analysts add entries; vendors can submit them.
• Product-scoped, not package-scoped. "OpenSSL 3.0.13" gets one CPE regardless of whether you got it from apt, vcpkg, or a Yocto recipe.
• What the NVD speaks. Every CVE in the NVD has a configurations block listing affected CPEs. Querying "what CVEs apply to my SBOM" through the NVD API means querying by CPE.
• Lags reality. CPE entries for new packages, niche libraries, embedded RTOSs, and vendor-specific drivers often don't exist, or exist with the wrong vendor/product slug. The NVD has publicly acknowledged this backlog.

What PURL is

Package URL is a specification maintained on GitHub by the PURL community. It identifies a package by the ecosystem it came from:

pkg:npm/lodash@4.17.21
pkg:pypi/cryptography@42.0.5
pkg:maven/org.bouncycastle/[email protected]
pkg:cargo/[email protected]
pkg:golang/golang.org/x/[email protected]
pkg:deb/debian/[email protected]?arch=amd64
pkg:generic/openssl@3.0.13?download_url=https://www.openssl.org/source/openssl-3.0.13.tar.gz

Key properties:

• Decentralized. No registry. You generate the PURL from the package metadata you already have. pkg:npm/... means "npm registry"; pkg:pypi/... means "PyPI"; the resolver is implicit in the type.
• Package-scoped, not product-scoped. Two PURLs from different ecosystems can describe what humans call "the same library" - pkg:npm/openssl-binding is different from pkg:generic/openssl even though they wrap the same C code.
• What CycloneDX speaks natively. Every CycloneDX component carries a purl field. SPDX 2.3+ supports PURL as an externalRef of type package-manager.
• Built for software supply chain reality. Transitive dependencies, lockfile versions, hashed sources - PURL was designed to mirror the way real software is shipped.

The comparison table

Why medical device SBOMs end up needing both

The FDA's February 2026 final guidance requires that every component in an SBOM carry a "unique identifier" and explicitly names PURL and CPE as acceptable. That phrasing is permissive - but the operational reality of running a device program for ten years post-clearance is not.

Premarket (build-time) leans PURL. Your CycloneDX or SPDX SBOM is generated by tooling - Syft, cdxgen, Microsoft's SBOM tool, your build system - that parses lockfiles, scans binaries, and emits PURLs. This is where 80-95% of components in a typical SaMD or connected-device SBOM live: open-source libraries shipped through npm, PyPI, Maven, NuGet, Cargo, apt, dnf, or pulled into a Yocto/Buildroot image.

Postmarket (monitoring) leans CPE. Once the device is in the field, you need a feed of "new CVEs that affect components on this device." The NVD is the canonical CVE source. NVD CVEs are indexed by CPE. Ecosystem-native feeds (OSV.dev, GHSA) cover PURLs well for open-source - but the NVD is still where most automated vulnerability tooling, government threat feeds, and CISA KEV cross-references resolve. You need CPE coverage to talk to that ecosystem.

Commercial, embedded, and firmware components live in CPE territory. An RTOS (FreeRTOS, VxWorks, QNX, embOS), a Bluetooth stack, a TCP/IP stack (lwIP, Treck), a chipset driver, a commercial database, the operating system on your gateway - these typically have CPE entries but no meaningful PURL. If you ship a class-II device with a connected hub, that hub's OS and firmware identifiers are CPE-only in practice.

Result: a mature medical device SBOM carries PURLs for everything generated from a package manager, CPEs for OS/firmware/commercial components, and - critically - a CPE for the device itself as a product so future CVEs can be attached to it by researchers.

How to map PURL to CPE (and where it breaks)

There is no official PURL ↔ CPE mapping. Several open-source projects try:

• purl2cpe - community mapping database
• OWASP Dependency-Track - maintains its own internal mapping when querying the NVD
• Anchore Grype, Trivy, Syft - each ships a vulnerability matcher that bridges PURL → CPE for NVD queries plus PURL → OSV for ecosystem-native queries
• CycloneDX SBOM tools - increasingly emit both purl and cpe fields on the same component when a mapping is known

Where it breaks in real medical device programs:

1. Vendor/product slug ambiguity. pkg:pypi/cryptography maps to cpe:2.3:a:pyca:cryptography:* - but only if your tooling knows that. Pick the wrong vendor slug and your NVD query returns nothing.
2. Statically-linked C libraries discovered by binary analysis. A binary SBOM tool emits pkg:generic/openssl@3.0.13 because there's no package manager involved. Mapping pkg:generic/... to a CPE is best-effort.
3. Forked or vendored libraries. Your team forked lwIP two years ago and ships a modified copy. The PURL points to a git repo that's not in any package manager; the CPE points to upstream lwIP CVEs that may or may not apply to your fork.
4. Vendor-supplied drivers and SDKs. A chipset SDK from a silicon vendor has no PURL and no CPE. It's a tarball with a version number. You have to either get the vendor to register a CPE or accept that postmarket CVE monitoring for that component is manual.
5. NVD analyst lag. A new CVE published last week may not have its CPE configuration block populated yet. PURL-native feeds (OSV, GHSA) often see it first.

The practical rule: never rely on a single identifier or a single feed. Run NVD-by-CPE and OSV-by-PURL and CISA KEV and vendor PSIRT feeds in parallel, deduplicate hits, and triage every hit with a VEX statement.

FDA postmarket implications

Section 524B requires "a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities and exploits in a reasonable time." The FDA's postmarket cybersecurity guidance and the February 2026 premarket guidance both make clear that "identify" means a continuous, machine-readable matching process between your shipped SBOM and live vulnerability feeds.

Reviewers and inspectors increasingly ask three operational questions about identifier hygiene:

1. "Show me a component on the device that does not have a CPE." If your answer is "we monitor it through PURL on OSV.dev," that's acceptable - but you need the documented process that shows you're doing it.
2. "Show me how you handle a CVE that's published to the NVD but doesn't yet have a CPE configuration." This is increasingly common given the NVD backlog. Your runbook needs to address it.
3. "Show me the VEX statement for the last three CVEs your SBOM matched." VEX is how you tell reviewers, customers, and CISA whether an apparent vulnerability is actually exploitable in your device's intended-use context.

The identifier choice is upstream of all three. If your SBOM components carry both PURL and CPE wherever possible, you can answer those questions credibly. If your SBOM is PURL-only or CPE-only, you have to explain why - and the explanation has to be defensible.

Practical guidance for medical device teams

1. Generate your build-time SBOM in CycloneDX 1.5+ with PURLs for everything sourceable from a package manager. This is what CycloneDX is good at and what your build tooling will produce automatically.
2. Add CPE for OS, firmware, RTOS, commercial libraries, vendor drivers, and the device itself. Use the NVD CPE Dictionary to find the right strings. Register a CPE for your device under your company's vendor slug.
3. Where both exist, ship both. CycloneDX lets you emit purl and cpe on the same component. Do it.
4. Run multi-feed monitoring. NVD (CPE), OSV.dev (PURL), GitHub Advisory Database (PURL), CISA KEV (CPE-keyed), and vendor PSIRT feeds for anything commercial. Deduplicate on CVE ID.
5. Triage every hit with VEX. A CVE match without a VEX statement is just noise on a reviewer's desk. See VEX Documents for Medical Devices for the workflow.
6. Document your identifier strategy in your postmarket cybersecurity plan. Reviewers want to see that you've thought about this - not that you happened to land on PURLs because your tooling did.

How Blue Goat Cyber Approaches SBOM Identifier Strategy

CPE vs PURL is not an academic distinction - it decides whether your vulnerability monitoring actually catches the CVEs FDA expects you to catch. Here is how we handle it on client engagements.

• Dual-identifier SBOMs by default. We emit both purl (for OSS package matching) and cpe (for NVD/CVE matching) on every component where a CPE exists, so vulnerability feeds line up regardless of which identifier the advisory uses.
• Deterministic PURL generation. PURLs come from the build system, not from post-hoc string manipulation - eliminating the mismatched-namespace bug that breaks most homegrown SBOMs.
• CPE mapping curated against NVD. For commercial and firmware components we verify CPE strings against the NVD dictionary rather than accepting scanner guesses.
• Traceability to design controls. Every SBOM revision is versioned in your QMS and tied to the software build that produced it, so postmarket vulnerability decisions are defensible.
• Postmarket monitoring wired in. SBOMs feed into an automated vulnerability watch that flags new CVEs against both identifier systems and routes them into your CAPA process.

Our FDA-Compliant SBOM Services engagement is the standard entry point.

FAQ

Does the FDA prefer CPE or PURL?

Can I get away with PURL only?

Can I get away with CPE only?

Who creates a CPE for my device?

How does VEX fit in?

Does CycloneDX or SPDX handle PURL/CPE better?

Related guides

• FDA SBOM requirements - the full submission baseline these identifiers feed.
• SBOM Vulnerability Management for Medical Devices
• VEX Documents for Medical Devices and the FDA
• CycloneDX vs SPDX: Choosing an SBOM Format for the FDA
• FDA Premarket Cybersecurity Submission Checklist
• FDA Section 524B Cybersecurity Requirements Explained

Free tools for this

• SBOM Readiness Checker - check an SBOM against the FDA's expected fields before you submit it.

References

• FDA, "Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions," final guidance, February 2026
• Section 524B of the Federal Food, Drug, and Cosmetic Act
• NIST, "Official Common Platform Enumeration (CPE) Dictionary," nvd.nist.gov/products/cpe
• PURL Specification, github.com/package-url/purl-spec
• CycloneDX 1.6 Specification, cyclonedx.org/specification
• SPDX 2.3 Specification, spdx.github.io/spdx-spec
• OSV.dev, "A distributed vulnerability database for open source," osv.dev
• CISA, "Known Exploited Vulnerabilities Catalog," cisa.gov/known-exploited-vulnerabilities-catalog