A device master file is the supplier's secret, not yours

This blog has already drawn the line between a device's specification developer and its contract manufacturer, and between a relabeler and the manufacturer whose name actually goes on the 510(k) — both posts about which party in a multi-firm supply chain owns which regulatory duty. A device master file answers a different question entirely: not who owns the duty, but who gets to see the data behind it. A component supplier, a sterilization contractor, or a raw-material vendor can hold information FDA needs to review a customer's submission without ever handing that information to the customer at all.

A master file lets FDA see what the sponsor never does

FDA's own master-file program — governed through 21 CFR 814.20(c) for PMA submissions, and extended by the agency's own practice to 510(k)s and IDEs as well — exists to solve one specific problem: a sponsor's premarket submission has to describe the methods, facilities, and controls used to manufacture the device, but a supplier two tiers up the chain usually will not hand its own customer the formulation, the sterilization cycle, or the tooling drawings that make that description complete. 21 CFR 814.3(d) defines a master file as a reference source a person submits to FDA that can contain exactly that kind of detail — manufacturing facility, process, methodology, or component information — filed directly with the agency rather than through the sponsor at all.

The sponsor's own file carries a letter, not the data

What crosses into the sponsor's own submission is a single document: a Letter of Authorization, issued by the master file's holder, naming the master file by its own assigned number, naming the sponsor by name, and stating the scope of what FDA may review inside it on that sponsor's behalf. The letter goes on the holder's own letterhead, and FDA's guidance expects the original to land inside the sponsor's submission with copies following any subsequent amendment — but the letter is the whole of what the sponsor's own file ever contains. The data the letter unlocks stays inside the master file, reviewed by the FDA reviewer assigned to the sponsor's application and never released to the sponsor or to the public.

One holder, many sponsors, one file

The arrangement is built to run in parallel across customers a supplier never discloses to each other. A single master-file holder can issue a separate Letter of Authorization naming each of its OEM customers in turn, each authorization unlocking the same underlying file for a different sponsor's own application, without any one sponsor learning who else is authorized against it. That is the entire point of filing the data once, centrally, rather than inside every customer's own submission: the supplier discloses its own trade secret to FDA exactly once, and grants access to it, sponsor by sponsor, through a one-page letter instead of a repeated disclosure.

The sponsor still can't see it, but still owns it

Access to a master file runs one way: FDA's reviewer can read it, the holder maintains it, and the sponsor whose submission depends on it never does. That asymmetry doesn't touch where responsibility for the finished device sits. A 510(k) or PMA holder is still the party FDA holds to account for the device's safety and effectiveness, including whatever a referenced master file says about the component or process it covers. A sponsor that treats a referenced master file as someone else's problem, because it never got to read the file, has confused who sees the data with who answers for it.

An authorization, once used, is not easily taken back

FDA's own guidance treats a spent authorization as durable rather than revocable at will: once the agency has referred to a master file in reviewing a submission and that submission has been approved, the authorization behind it cannot be withdrawn. A supplier that grants access expecting to retract it later, the way a services contract might be terminated, is picturing a right the master-file system was not built to give back. A sponsor relying on someone else's master file is leaning on an authorization that outlives the business relationship that produced it.

Where this meets the file

A submission's own file needs the master-file dependency tracked as its own line item: the file number it relies on, the Letter of Authorization that unlocked it, the date that authorization was granted, and whether the authorization names this submission specifically or a broader scope. A supplier-dependency worksheet built around that structure, alongside the launch catalog's other submission-readiness templates, is previewed there now. If your program tracks master-file dependencies differently, the shelf takes that correction directly.