Where the UDI has to resurface after it leaves the label

A unique device identifier's job looks finished the moment it's printed correctly on the label and the package, meeting 21 CFR 801.20 and the technical requirements of Part 830. That's the easy, visible half of the requirement. The harder half is what happens to that same identifier after the device leaves the building — whether it changes when the device does, whether it's kept current in FDA's Global Unique Device Identification Database, and, since the Quality Management System Regulation took effect on February 2, 2026, whether it reappears correctly in the complaint file and the service record under 21 CFR 820.35. A UDI record that stops at the label is tracking a print job, not the identifier's actual life.

Two different sections do two different jobs

21 CFR 801.20 is the labeling rule: the label of every device, and its device package, has to bear a UDI, subject to the exceptions at 801.30 and a handful of other provisions. That section says a UDI has to be there. It doesn't say what makes the identifier itself valid — that's Part 830's job, and specifically 830.20, which requires the UDI to be issued under a system operated by FDA or an FDA-accredited issuing agency, built from a device identifier (the fixed part naming the specific version or model and its labeler) and, where the device carries one, a production identifier — lot, batch, serial number, or manufacture and expiration dates. A device record that can show a UDI printed on the label but can't show which issuing agency's system generated it, or which production-identifier elements it's required to carry, has satisfied 801.20's letter without being able to answer what 830.20 actually asks.

The identifier is not fixed for the life of the device

830.40 governs use and discontinuation of a device identifier, and 830.50 is the section a labeling record most often misses entirely: it requires a new device identifier once a change to the device meets the criteria the section sets out, rather than letting the existing identifier carry forward with an updated description behind it. A UDI record built only to confirm a number was assigned once, at launch, has no field for the question 830.50 actually asks on every design change — does this change require a new device identifier, or does the existing one still hold. Skipping that question doesn't just risk a labeling error; it risks a device shipping under an identifier that no longer accurately describes what it identifies.

Class I gets one specific carve-out, not a blanket exemption

801.20 also narrows the requirement for Class I devices: their UDI isn't required to include a production identifier. That's a specific, limited relief on one component of the identifier — not an exemption from bearing a UDI at all, and not a license to skip the device-identifier requirements Part 830 sets for every class. A record that treats “Class I” as shorthand for “UDI requirements don't apply here” has generalized a narrow carve-out into one the regulation doesn't grant.

The database side doesn't close when the label ships

Subpart E of Part 830, starting at 830.300, requires labelers to submit data for each version or model to the Global Unique Device Identification Database and keep it current. That's a standing obligation, not a one-time filing alongside the label's first print run — a GUDID record that was accurate at launch and never updated against a subsequent 830.50 device-identifier change is now wrong in FDA's own database, not just stale on a shelf somewhere. A UDI record structured around a single “submitted: yes” field, with no trigger tying it back to the change log, is the database-side version of the same gap 830.50 creates on the label side.

What the QMSR added: the identifier has to travel

The clearest sign a UDI record's job doesn't end at the label is downstream, in the records the QMSR governs directly. 21 CFR 820.35, the control-of-records section FDA retained alongside its adoption of ISO 13485:2016, requires documentation sufficient to meet Part 830's UDI requirements to appear in complaint records, and requires service records to capture the device's UDI or other identification alongside the date of service, the servicing engineer, and the nature of the work performed. A complaint log that records a device description in prose — model name, approximate age — without the specific identifier that record is now supposed to carry is short of what 820.35 asks for as of February 2, 2026, even if every other field on the form is filled in correctly.

A UDI record built around this full chain — the label requirement at 801.20, the identifier's construction and change rules under Part 830, the standing GUDID obligation, and the downstream fields 820.35 now requires it to reach — is previewed in the launch catalog. Sources move, the same way any mapped resource can drift from what it cites; if your team has caught a UDI gap this record doesn't, the shelf takes that correction directly.