Your PLM can tell you that hardware revision C pairs with firmware v4.5. It has no idea whether the unit sitting in a customer's garage right now, serial number 4,812, is actually running it.
That gap isn't a bug in your tooling. It's a category error nobody's forced to notice yet, because most PLM and PDM systems were built to manage parts that don't change after they ship. Firmware changes after it ships. Sometimes you change it yourself, over the air, on a device you'll never physically touch again.
Firmware Is a Line Item, Not an Afterthought
Treat firmware the way you'd treat any other custom part: give it a line on the BOM. It doesn't need a cost attached to it, since you're not purchasing it, but it needs the same discipline as everything else on that BOM: a defined revision, a change history, and someone responsible for it.
The firmware itself should live in git, GitHub or GitLab or wherever your team already works. That part isn't new advice; every engineer already knows to version control code. What's usually missing is the bridge from that git tag back to the BOM line it belongs to. Hardware revision C of your board pairs with firmware v4.5, not v4.4 and not v4.6, and that pairing is exactly the kind of dependency a BOM exists to record. Every firmware release that changes what actually ships is a change to your product, and it deserves the same tracked-change record as anything else on the BOM, not a version number quietly edited in a spreadsheet cell.
This isn't a novel idea, even if nobody selling PLM to hardware startups talks about it. Visure Solutions calls it an Embedded BOM: one that folds firmware binaries in alongside mechanical parts and electronic components specifically so a factory always flashes the correct build onto the correct hardware revision. OWASP's CycloneDX standard, which most security teams already use for software bills of materials, goes further and defines firmware as its own component type, distinct from but explicitly linked to the physical device it runs on. If you were wondering whether firmware actually belongs in a bill of materials, the answer already has a name.
What Your Contract Manufacturer Actually Needs
A CM handoff already needs assembly instructions, labeling, and a test procedure before anyone builds a unit. Programming that unit is its own step, and it needs its own artifact.
What you hand over is a compiled binary: a .hex file for a microcontroller, or a disk image for anything running Linux on an SBC. Never the raw source. Shipping source to a CM buys you nothing operationally and hands over a security surface you didn't need to hand over.
The binary by itself isn't enough either. What actually prevents confusion on the line is a short release note that travels with it: the file name and version, the board revision it targets, a checksum or hash so nobody mixes up firmware_v1.3.7.hex with whatever got renamed and re-emailed three revisions later, the programming method (in-circuit, a bed-of-nails fixture, or a pre-programmed IC before it hits the line), any security or lock-bit settings, and how serial numbers or MAC addresses get assigned during the flash. Attach that note to the same BOM line as the binary. A good PDM or PLM should let you store the artifact directly against the part, so your CM pulls it from the same system they pull the rest of your BOM from, not a Slack thread from three weeks ago.
The Gap No PLM Closes
None of that solves the harder problem, and it's worth being honest about where the tooling actually stops. Your PLM can log that you pushed firmware v4.5 on a given date. It cannot tell you which of the 3,000 units you've shipped are actually running it.
That's a different question, and it belongs to a different system. Fleet-level device management, the kind Particle or Mender provide, answers what firmware a specific serial number is running right now, today, in the field. Your PLM answers what firmware a hardware revision is supposed to run. Both are true statements about the same product, and no tool on the market cleanly owns both.
If that split sounds familiar, it should. It's the same design-intent-versus-what-actually-shipped problem as your eBOM and your mBOM, just playing out at the device level instead of the assembly level. This is also a different problem than whether your BOM covers mechanical, electrical, and firmware as one product; that question is about scope. This one is about time: whether the record you have reflects what's true right now, in the field, versus what was true the day you shipped.
The compliance world already has a name for the split, even if PLM vendors selling to hardware startups don't use it yet. A Hardware Bill of Materials, or HBOM, distinguishes a design-intent record (what firmware a component is supposed to run) from an as-built record (the firmware image, debug-lock state, and serial or lot range an actual unit shipped with). Your BOM is the design-intent half. The as-built half lives wherever your OTA updates actually get pushed and logged, and if that system isn't talking to your BOM, you have two records of the truth and no way to reconcile them when a unit comes back with a problem.
No PLM solves fleet-level OTA tracking today, oroForge included. What a good one can do is be the system of record for the intended pairing, hardware revision to firmware version, and hold the documentation your team generates about a release, so the design-intent half is never in question. The as-built half still needs a device-management platform doing its job next to it.
This Is About to Become a Legal Problem, Not Just an Operational One
If you sell into the EU, this stops being a nice-to-have soon. The EU Cyber Resilience Act requires a machine-readable software bill of materials for any product with digital elements, and firmware counts as software under the Act's definition. That SBOM has to be updated every time you ship a firmware update, not generated once and filed away.
The timeline isn't far off. Incident and vulnerability reporting obligations became mandatory on September 11, 2026, a week before this was written. Full compliance, including the SBOM requirement, secure-by-design obligations, and conformity assessment, is due December 2027. Hardware development cycles run long enough that a product you're speccing today will likely still be shipping when that deadline arrives.
Read that against the gap in the last section. A regulator asking which units are affected by a firmware vulnerability is asking exactly the as-built question your PLM can't currently answer on its own. Building the design-intent half cleanly now is the part you can actually control before the deadline forces the rest.
The Firmware Nobody Talks About
There's a second kind of firmware that never ships in the product and still needs the same discipline: the code that runs your test fixtures and programs the board on the line. It's not what the customer's unit runs; it's what confirms the customer's unit was built correctly.
This code changes far less often than product firmware, which is exactly why it gets neglected. Nobody revisits a bed-of-nails test script for eighteen months, and then a fixture gets swapped or a test point moves and nobody can say which version of the test firmware belongs with the new hardware. Track it as its own artifact, version controlled the same way as everything else, because your CM needs a current copy of it just as much as they need the product firmware, and for the same reason: without it, they can't tell you whether a unit passed.
One BOM, Two Kinds of Truth
A BOM built around firmware answers one question well: what's supposed to be on this device. It was never going to answer the other one, what's actually on it, and pretending otherwise just hides the gap until a field failure or a compliance audit forces you to find it the hard way.
Track the pairing. Hand your CM a binary and a release note, not a raw repo. Keep production test firmware under the same discipline as the code that ships. And go in knowing the fleet-state question needs a different system sitting next to your BOM, not inside it. See pricing before that gap gets expensive to close after the fact.
