For medical devices — read this first
This is the page where we tell you not to buy yet. Manufacturing PLM is missing three capabilities a device manufacturer needs, and none of them are the kind you work around.
The three gaps, stated first
Design controls. A structured design history covering user needs, design inputs, outputs, review, verification, validation and transfer, with traceability between them. Manufacturing PLM has requirements and verification objects that were deliberately built general enough to carry this later, but the structured design-controls package does not exist today.
A device history record. Per-unit manufacturing evidence — what was built, from which lot, by whom, against which inspection results. Manufacturing PLM holds the design side and stops at execution; the DHR lives where the building happens.
ISO 14971 risk management. A risk file linking hazards to harms to controls to residual risk, maintained across the product lifecycle. FMEA exists here and is not the same artefact, and presenting one as the other would be the wrong kind of shortcut.
None of the three is a roadmap item with a date. Choosing a PLM on a roadmap promise is how organisations end up migrating twice, and we would rather lose this deal than be the reason for the second migration.
What we deliberately have not claimed
The audit trail is hash-chained, refuses unattributed writes, and gives administrators no silent bypass. Approvals are authenticated acts bound to an object revision with a recorded meaning. Released revisions are immutable.
That is the right foundation and it has not been validated against 21 CFR Part 11. We will not claim compliance we have not tested, because a compliance claim on a public page is exactly the kind of statement somebody relies on when they should not — and in this industry the person relying on it is signing something.
The same applies to electronic signatures: authenticated, attributed and audited, but not a validated Part 11 signature and not an eIDAS qualified one.
What does work well, if you are pre-submission
There is a real case for a device company that is not yet in a regulated build: an early-stage team designing hardware, running suppliers, controlling drawings and managing change, who will need design controls before submission but does not need them this quarter.
For that team the ordinary strengths apply. Change control with a computed impact set. Revisions that distinguish released from in-progress. Effectivity across date, unit and plant. A supplier portal whose isolation is enforced at the data layer. Component risk joined to the parts you actually buy.
The requirements and verification model is the piece that matters for your future. It was built so a design-controls package could sit on it without re-modelling — traceability from requirement to test to part to evidence is already the shape of the data.
That is a genuine argument for starting here and a poor argument for staying if your submission timeline is short.
How to decide
If you are in or near a regulated build, buy something else. Arena, Propel and the established device-specific vendors have design controls, a DHF and validated Part 11 signatures today. That is the correct answer and we will say so on a first call rather than three weeks into an evaluation.
If you are pre-submission by more than a year, there is a real conversation to have about whether the change control and supply-risk capabilities are worth having now, with a migration to a validated system later — or whether one migration is better than two.
If you make devices that are not regulated as devices — laboratory instruments, veterinary equipment, wellness hardware — the gaps above may not apply to you at all, and the ordinary electro-mechanical case holds.
How it meets your ERP
The ERP story is unaffected by any of the above and is one of the stronger reasons a device company might still be interested. Item identity, released BOM and change records master in Manufacturing PLM; cost, on-hand, lead time and supplier records master in your ERP; the matrix is published per connector.
Lot and batch context reads back where the connector exposes it, which matters for a device manufacturer even without a DHR — knowing which lots a nonconformance touches is the front half of a containment decision.
What Manufacturing PLM does not do is act on it. Disposition, quarantine and recall execution are decisions made with inventory in front of somebody and transacted where the stock lives.
Where the boundary is
Beyond the three gaps: no validated system, no IQ/OQ/PQ documentation package, no supplier qualification workflow specific to device regulation, and no complaint handling tied to reportability decisions.
We would also rather not be your quality system's system of record while these gaps exist. A device company running quality here and design controls elsewhere has two systems of record for closely coupled data, which is a worse position than either system alone.
The honest summary is that Manufacturing PLM is a good PLM that is not yet a device PLM, and the distance between those two things is measured in regulatory capability rather than in features. We would rather write that down on a public page than let somebody discover it during a submission.
Facts
| Missing | Design controls — no structured DHF package |
| Missing | Device history record — per-unit build evidence |
| Missing | ISO 14971 — FMEA is not the same artefact |
| Not claimed | 21 CFR Part 11 validation · eIDAS qualified signatures |
| Foundation exists | Hash-chained audit · immutable revisions · attributed approvals |
| Built to carry it later | Requirements and verification traceability |
| Buy elsewhere if | You are in or near a regulated build |
| May still fit if | Pre-submission by a year, or not device-regulated |
Frequently asked
Can we use Manufacturing PLM for a regulated device?
Not today. Design controls, a device history record and ISO 14971 risk management are all absent, and none of them are the kind of gap you work around with configuration. If you are in or near a regulated build, buy one of the established device vendors.
Is FMEA the same as ISO 14971?
No, and presenting one as the other would be the wrong kind of shortcut. FMEA analyses failure modes on a design or process. A 14971 risk file links hazards to harms to controls to residual risk across the lifecycle — a different artefact with a different audience.
Are you Part 11 compliant?
No, and we will not claim it. The foundation is right — a hash-chained audit trail, refused unattributed writes, authenticated approvals bound to object revisions — but it has not been validated. In this industry the person relying on such a claim is signing something.
Is this on your roadmap?
Not with a date, deliberately. Choosing a PLM on a roadmap promise is how organisations end up migrating twice, so we would rather lose the deal than be the reason for the second migration. Treat the gaps above as permanent for planning purposes.
We are pre-submission. Should we start here?
There is a real conversation to have. The change control, revision, effectivity and supply-risk capabilities are genuinely useful now, and the requirements model was built to carry design controls later — but one migration is often better than two, and that is your call.
What if our product is not regulated as a device?
Then the gaps described above may not apply to you at all. Laboratory instruments, veterinary equipment and wellness hardware frequently sit outside device regulation entirely, and in that case the ordinary electro-mechanical argument holds without a single one of these caveats.
Could we run quality here and design controls elsewhere?
We would rather you did not. That arrangement gives you two systems of record for closely coupled data — nonconformances here, design history there — which is a worse position than either system alone and creates exactly the reconciliation problem an audit will find.