SBOM Formats Compared: What FDA, MFDS, and EU MDR Actually Want
Software Bill of Materials (SBOM) requirements differ between FDA, MFDS, and EU MDR. Here's a side-by-side comparison and recommendations for multi-jurisdiction submissions.
What Is SBOM and Why It Matters
SBOM allows manufacturers and regulators to:
- Identify vulnerable components when CVEs are published
- Track software supply chain dependencies
- Plan vulnerability response and patching
- Demonstrate post-market vigilance for software
Three Major SBOM Formats
CycloneDX (OWASP)
- Originated: 2017 by OWASP Foundation
- Current version: 1.5 (2023)
- Format: JSON, XML, Protobuf
- Strengths: Strong vulnerability integration (VEX support), wide tooling ecosystem
- Adoption: Highest among software security tools
SPDX (Linux Foundation)
- Originated: 2010 by Linux Foundation
- Current version: 2.3 (2022)
- Format: JSON, XML, RDF, YAML, Tag-Value
- Strengths: ISO/IEC 5962 international standard, strong license tracking
- Adoption: Common in open source compliance
SWID Tags (ISO/IEC 19770-2)
- Originated: 2009 by NIST/ISO
- Current version: ISO/IEC 19770-2:2015
- Format: XML
- Strengths: Designed for software identification
- Adoption: Less common in medical devices
Regulatory Requirements Comparison
FDA (Final Guidance 2023)
Required: SBOM at premarket submission for cyber devices.
Format: Manufacturer choice; NTIA Minimum Elements must be included.
Required elements:
- Author name
- Timestamp
- Component name
- Component version
- Component supplier
- Component hash (when available)
- Component relationships
Format preferences:
- CycloneDX or SPDX commonly used
- Vendor-proprietary formats acceptable if NTIA elements present
Update requirements: SBOM update with significant software changes.
MFDS (Notice 2026-12, Effective July 2026)
Required: SBOM mandatory for Class II+ connected, firmware, or SaMD devices.
Format: SPDX 2.3 or CycloneDX 1.5 (specific versions required).
Required elements (beyond NTIA minimums):
- CVE references at time of submission for all components
- Update mechanism for each component
- Korean-language summary of critical components
Update requirements: SBOM update with each change notification.
EU MDR (MDCG 2019-16, MDCG 2024-X update pending)
Required: SBOM recommended but not strictly mandated in MDR text.
Format: Flexible; CycloneDX, SPDX, or vendor-specific.
Required elements: Less prescriptive than FDA/MFDS, but expected to support post-market vigilance.
Update requirements: Aligned with PMS plan.
Side-by-Side Format Comparison
| Aspect | CycloneDX 1.5 | SPDX 2.3 | SWID Tags |
|---|---|---|---|
| FDA accepted | Yes | Yes | Yes (with NTIA elements) |
| MFDS accepted | Yes | Yes | No (post-2026) |
| EU MDR accepted | Yes | Yes | Yes |
| Vulnerability tracking (VEX) | Native | Add-on (VEX-SPDX) | Limited |
| License tracking | Good | Strongest | Limited |
| Cryptographic hash | Native | Native | Native |
| Update tracking | Good | Good | Native (designed for this) |
| Tooling ecosystem | Largest | Large | Smaller |
| ISO/IEC standardization | No | Yes (5962) | Yes (19770-2) |
Recommended Multi-Jurisdiction Strategy
For manufacturers submitting to FDA + MFDS + EU MDR:
Strategy 1: CycloneDX Primary, SPDX Backup
- Generate CycloneDX 1.5 as primary SBOM
- Auto-convert to SPDX 2.3 when SPDX explicitly requested
- VEX (Vulnerability Exploitability eXchange) in CycloneDX for vulnerability disclosure
- Korean summary document for MFDS
Advantages: Single source of truth, strong tooling, vulnerability tracking integrated.
Strategy 2: SPDX Primary, CycloneDX Backup
- Generate SPDX 2.3 as primary
- Auto-convert to CycloneDX when needed
- License compliance metadata strong
- Korean summary document for MFDS
Advantages: ISO standard, license tracking, common in open source projects.
Strategy 3: Dual-Format Generation
- Generate both CycloneDX and SPDX in pipeline
- Submit appropriate format per jurisdiction
- Most flexible, slightly higher generation cost
Recommended for: Manufacturers with multiple products and varying jurisdiction requirements.
SBOM Generation Tools
| Tool | Format | Strengths |
|---|---|---|
| Anchore Syft | CycloneDX, SPDX | Comprehensive component discovery |
| CycloneDX Maven/npm plugins | CycloneDX | Native build integration |
| SPDX SBOM Generator (Microsoft) | SPDX | Microsoft ecosystem integration |
| Tern | SPDX, CycloneDX | Container scanning |
| OWASP Dependency-Track | CycloneDX | Continuous monitoring + VEX |
Selection depends on tech stack (Java, Node.js, Python, container-based, etc.).
Common SBOM Mistakes
Mistake 1: SBOM Generated Once, Never Updated
SBOMs go stale within weeks. Components update; new CVEs emerge.
Fix: Generate SBOM in CI/CD pipeline; update SBOM at every release.
Mistake 2: Missing Transitive Dependencies
Direct dependencies captured; transitive (dependency-of-dependency) missed.
Fix: Use tools that resolve dependency tree (e.g., npm ls --all, mvn dependency:tree).
Mistake 3: Vulnerable Components Not Flagged
SBOM lists components without CVE cross-reference. Regulators want vulnerability visibility.
Fix: Integrate with vulnerability database (NVD, OSV.dev) and include CVE annotations.
Mistake 4: Korean Submission Without Localization
MFDS expects Korean summary; SBOM file alone insufficient.
Fix: Korean executive summary of critical components and key vulnerabilities.
Mistake 5: SBOM Doesn't Match Shipped Product
SBOM generated from development environment differs from production build.
Fix: Generate SBOM from final production build artifacts.
SBOM Lifecycle Best Practices
Development Phase
- Generate SBOM at each build (CI/CD integration)
- Validate completeness against expected components
- Flag vulnerable components before merge
Submission Phase
- Generate final SBOM from production build
- Cross-reference against NVD for current vulnerabilities
- Add jurisdiction-specific supplementary documentation
Post-Market Phase
- Monitor SBOM components for new vulnerabilities (daily monitoring recommended)
- Assess vulnerability impact (VEX statements for not-affected components)
- Update SBOM with each release
- Notify regulators of critical vulnerability discoveries per timeline
Frequently Asked Questions
Q: If we use proprietary or commercial software in our device, must we include their components in SBOM?
A: Yes, all components must be listed. For commercial software, list the product name and version; you don't need to disclose the proprietary internals beyond the supplier's published information.
Q: How do we handle open source license obligations in SBOM?
A: SPDX format has the strongest license tracking. Include license identifiers (SPDX License List) for each component. CycloneDX also supports licenses but with less standardization.
Q: Do we need to disclose all CVEs, or just unpatched ones?
A: Best practice: list all known CVEs with status (mitigated, patched, accepted risk). VEX (Vulnerability Exploitability eXchange) format in CycloneDX is designed for this.
Q: How does Leanabl help with SBOM?
A: Leanabl's Medical Device Cybersecurity service includes SBOM generation strategy, format selection, jurisdiction-specific documentation, and post-market monitoring plan.
Q: Will EU MDR make SBOM mandatory soon?
A: MDCG 2024 update under discussion is expected to strengthen SBOM expectations. Implementation timeline uncertain but recommend treating as required for new submissions.
How Leanabl Helps
- Medical Device Cybersecurity — SBOM strategy and submission preparation
- Korea SaMD Approval — for AI/ML devices with cybersecurity complexity
- Korea Medical Device Registration — full registration with cybersecurity
Contact Leanabl for SBOM strategy.
Last updated: 2026-05-15.
Have a regulatory question?
Talk to a Korea regulatory specialist about your device, your timeline, or your next submission.
Talk to a specialist
