Your BOM tells you what's on the board. It doesn't tell you what's running on it.
For an IoT product, that is the half that gets you the 2 a.m. support ticket. A unit in the field misbehaves, and the first question is not "what parts are on it." The first question is "which hardware revision is this, and what firmware version was validated against it." Most teams under 25 people cannot answer that quickly, because the two facts live in different systems owned by different people.
This is the part nobody warns you about when you pick a BOM tool. The tools assume your product is a thing you can model in CAD. An IoT product is three things stitched together, and only one of them lives in CAD.
The Product Is Three Sources of Truth
Pull apart any connected device and you find three products wearing one enclosure.
There is the mechanical assembly: the housing, the gaskets, the mounting hardware, the thermal pad. That lives in Onshape, SolidWorks, or Fusion 360. There is the board: the ESP32 or STM32, the regulators, the sensors, the passives. That lives in KiCad, Altium, or Eagle. And there is the firmware: the thing that makes the rest of it more than a paperweight. That lives in a git repo a firmware engineer owns.
Three products, three tools, three owners. The mechanical lead owns the first. The EE owns the second. The firmware engineer owns the third. Nobody owns the map between them.
That missing map is the actual problem. It is not that any one of these tools is bad at its job. It is that no one of them was built to know about the other two.
Your CAD's PDM Only Speaks Its Own Language
Every CAD vendor will tell you they solved BOM management. They solved it for their CAD.
SolidWorks PDM centralizes the BOM of things modeled in SolidWorks. Onshape keeps a clean BOM of what you built in Onshape. Vault does the same for the Autodesk side. Each one is genuinely good inside its own boundary, and each one stops dead at that boundary. If you want to understand what a PDM system actually does and where its scope ends, that boundary is the whole story.
Your IoT product crosses that boundary by definition. The enclosure is mechanical CAD; the board is electrical CAD; they are different files in different tools from different vendors. A single-vendor PDM cannot give you one BOM for a product that was never modeled in a single vendor's tool. It was never designed to.
So the electrical BOM gets exported from KiCad and pasted into a spreadsheet. The mechanical BOM gets exported from Onshape and pasted into the same spreadsheet, on a different tab. Someone hand-reconciles the two. The spreadsheet becomes the only place your whole product exists as one list, and it is maintained by hand, by one person, at the exact moment your team is moving fastest.
That spreadsheet is not your system of record. It is the scar tissue where two systems of record failed to meet.
Rev C Boards, Rev B Firmware
Hardware moves. By the time you have shipped a few hundred units, you are on your third board revision, and the revisions were not cosmetic.
You swapped a sensor because the original went to a twelve-week lead time. You changed a regulator because the first one ran hot. Each of those is a real electrical change, and some of them require a firmware change to match: a different register map, a new calibration constant, a driver that expects different silicon. Research on hardware lifecycles is blunt about how routine this churn is; a majority of new product versions ship with more BOM components than the version before them. The board you ship in month six is not the board you shipped at launch.
Now you push an over-the-air update. If you do not know which units are Rev C and which are Rev B, and which firmware build was validated against which board, that OTA push is a coin flip. The build that fixes a bug on Rev C can brick every Rev B unit in the field. You find out from support tickets, not from a dashboard.
This is the traceability gap, and it is specific to connected hardware. A purely mechanical product does not get a remote update that can break it. An IoT product does, every release cycle.
The minimum viable fix is not complicated, and it does not require a git integration to start. You attach the firmware binary, or a zipped build, to the specific hardware revision it was validated against, inside the same system that holds the BOM and the change history. Now the map exists. When a unit comes back, you look up its revision and you know the firmware that belongs with it. That is the floor. Native git integration is where this goes as your release cadence climbs; for a team shipping its first few production runs, an artifact pinned to a revision closes the gap that actually hurts.
The Silent Substitution
The most expensive change order on an IoT product is the one nobody filed.
Procurement hits a wall: the flash chip is on allocation, the sensor is end-of-life, the original part has a sixteen-week quote. They find an alternate, it is pin-compatible, it goes into the next build. On a mechanical product, a pin-compatible swap is usually the end of the story.
On an IoT product it is the start of one. The alternate flash chip has a different page size. The replacement sensor reports in different units. The firmware was written against the original, and now it is running against a part it has never met. The board powers on, passes a quick smoke test, and ships with a defect that only shows up under load in the field.
Call it the Silent Substitution. The part changed, the firmware did not, and the change order, if one existed at all, lived in a Slack thread that did not flag firmware as a downstream dependency. The fix is to treat a component swap on a connected product as what it is: a change that can ripple into code, logged where the people who own the code will see it.
What Minimum Viable PLM for IoT Looks Like
You do not need an enterprise PLM to close these gaps. You need a system of record that knows your product is electromechanical and connected, not just mechanical.
In practice that means three things. One BOM that holds both the mechanical and the electrical side, so the enclosure and the board live in the same structure instead of two spreadsheet tabs. Change control that links a part substitution to the revision it created and the people who need to sign off, so the Silent Substitution gets caught before it ships. And a place to pin the firmware build to the hardware revision it was validated against, so Rev C boards stop running Rev B code.
That is the scope oroForge is built for. Mechanical and electrical BOMs centralized in one place; ECO-based change control you can switch on when your team is ready, not before; and firmware artifacts attached to the hardware revisions they belong to. It is deliberately the minimum viable version. Native CAD sync and git integration are on the roadmap, because at enough volume they become indispensable for IoT; what ships today is the floor a team needs before it has the volume to justify the rest. See pricing for a free plan and a flat-rate Team plan for growing IoT teams.
The teams that get burned are not the ones with bad engineers. They are the ones who treated a connected, electromechanical product like a mechanical one with some code bolted on, and trusted a single-vendor PDM and a spreadsheet to hold it together. The product was always three things. The tooling has to know that.
If your IoT product lives across three tools and a spreadsheet today, oroForge gives it one place to live: oroforge.com.
