Published: May 22, 2026 · Last reviewed: May 1, 2026
A Form 483 used to be a quality-system document. Since QMSR took effect on February 2, 2026, it's also a cybersecurity document — and inspectors are writing observations that didn't exist 18 months ago.
If you're a medical device manufacturer that just hosted an FDA inspection, the Form 483 you got handed at the close-out meeting may look different from the last one. Cybersecurity findings — once buried in premarket review or postmarket guidance — are now showing up as inspectional observations against your quality system. That's because QMSR (21 CFR Part 820, as revised) folded ISO 13485:2016 in by reference and added 820.35 for postmarket activities, including cybersecurity.
This post walks through what a 483 actually is, the cybersecurity-flavored observations the FDA is now citing, and how to close them before they turn into a Warning Letter.
What a Form 483 actually is (and isn't)
Form FDA 483 is a list of inspectional observations issued at the end of an on-site inspection. It is not a final agency action. It is the inspector's documented list of things they believe deviate from the FD&C Act or its implementing regulations — in our world, QMSR (21 CFR Part 820) and the parts of 21 CFR Part 803 (MDR) that touch postmarket events.
Three things to know up front:
- A 483 is not a Warning Letter. It's the precursor. The FDA reviews your written response (typically due within 15 business days) before deciding whether to escalate.
- A 483 follows an inspection of a facility, not a desk review of a submission. That's the line between 483-world (postmarket, QMSR-driven) and deficiency-letter world (premarket, submission-driven).
- Cybersecurity observations on a 483 cite QMSR clauses, not the premarket cybersecurity guidance directly. The premarket guidance shapes what "good" looks like; QMSR is the regulation the inspector cites.
Why cybersecurity now shows up on 483s
Three regulatory changes converged to put cybersecurity on the inspector's checklist:
- Section 524B of the FD&C Act (effective March 29, 2023) made cybersecurity a statutory requirement for "cyber devices."
- The FDA's September 2023 / February 2026 premarket cybersecurity guidance defined what manufacturers are expected to produce, control, and maintain.
- QMSR (89 FR 7496), effective February 2, 2026, incorporated ISO 13485:2016 by reference and added 820.35, which explicitly extends quality system obligations to postmarket activities including complaint handling, servicing, and — by direct read — cybersecurity vulnerability response.
The net effect: an inspector walking your facility can now cite gaps in cybersecurity documentation, processes, or postmarket monitoring as QMSR observations on a 483.
Cybersecurity observations the FDA is citing on 483s
These are the patterns we're seeing across recent inspections of connected device manufacturers. Each one is a real inspector observation translated into the QMSR clause it tends to cite.
1. Missing or stale SBOM in the Design History File
"Design History File for [Device X] does not contain a complete software bill of materials reflecting the as-released software configuration."
Cited under 820.30 (design controls) and ISO 13485 7.3.7 (design and development verification/validation records). The FDA expects the SBOM that supported your premarket submission to be alive in the DHF and updated when software changes. A stale SBOM is now an observation, not a nice-to-have. See our SBOM vulnerability management guide for what "alive" means in practice.
2. No postmarket vulnerability monitoring process
"Manufacturer has not established a documented procedure for the ongoing identification, assessment, and disposition of post-release software vulnerabilities affecting marketed devices."
Cited under 820.35(a) (the new postmarket clause) and 8.2.2 / 8.4 of ISO 13485. This is the single most common cybersecurity-flavored 483 observation we see. The fix is not "subscribe to a CVE feed" — it's a documented, auditable process that ties vulnerability intake to your existing risk management, complaint handling, and CAPA workflows.
3. Security events not handled as complaints
"Cybersecurity events reported to the firm by customers were not processed through the established complaint handling system."
Cited under 820.198 / ISO 13485 8.2.2. If a hospital reports that your infusion pump dropped a session under suspicious circumstances, that's a complaint. If your complaint procedure can't ingest, classify, and escalate a security event the same way it handles a clinical event, that's a 483.
4. Software changes not flowing through design controls
"Software updates released to address security vulnerabilities were implemented without documented design verification or validation."
Cited under 820.30(i) / ISO 13485 7.3.9 (control of design and development changes). Patch fast, but patch through your change control system. Cybersecurity patches are design changes — they need verification, validation evidence, and a risk re-assessment recorded.
5. Risk file doesn't include cybersecurity hazards
"ISO 14971 risk management file does not address cybersecurity-related hazards or hazardous situations for the subject device."
Cited under ISO 13485 7.1 and ISO 14971 by reference. AAMI TIR57 and ANSI/AAMI SW96 are the two playbooks the FDA expects you to use to integrate cybersecurity into your risk file. If your risk file is silent on threat actors, exploit paths, and patient-harm pathways from a security event, expect this one.
6. No evidence of supplier cybersecurity controls
"Purchasing controls do not address cybersecurity requirements for software components, third-party libraries, or contract manufacturers handling device software."
Cited under 820.50 / ISO 13485 7.4. The FDA reads your SBOM and asks the obvious question: how did you qualify the supplier of every third-party component on that list? If purchasing records don't show cybersecurity criteria, it's an observation.
7. CAPA system doesn't trigger on cybersecurity trends
"Trends in cybersecurity-related complaints, vulnerability disclosures, or field events were not analyzed in the firm's CAPA system."
Cited under 820.100 / ISO 13485 8.5. CAPA is where the FDA looks for evidence that you're learning from postmarket signal. A spike in CVEs against one of your dependencies, three customer-reported security events in a quarter, a coordinated vulnerability disclosure — none of those can be invisible to CAPA.
From 483 to Warning Letter: how cybersecurity gaps escalate
The FDA's escalation path is consistent:
- 483 issued at the close of inspection. Response due in ~15 business days.
- Response reviewed. If the FDA finds the response adequate — concrete corrections, root cause, evidence, timelines — the file may close at the district level.
- Warning Letter issued when the response is weak, non-existent, or when observations are serious enough on their own. Warning Letters are public; 483s are not (though they're FOIA-able).
- Consent Decree, Import Alert, or Seizure in extreme or repeat cases.
Cybersecurity-flavored 483s escalate to Warning Letters when the response treats the finding as a documentation gap rather than a systemic process gap. "We've created an SBOM" is not a response. "We've established a documented procedure (Doc # SOP-XXX), trained the affected staff (training records attached), retrofitted the DHF for our three marketed products (DHF amendments attached), and added the procedure to our internal audit schedule" — that's a response.
How to respond to a cybersecurity 483 (the short version)
A defensible 15-day response has the same shape regardless of which observation you're closing:
- Acknowledge the observation literally. Don't argue with the inspector's wording.
- State the immediate correction. What you did this week.
- State the systemic corrective action. New or revised SOP, training, retroactive review of affected products.
- Provide evidence. SOP version, training records, DHF amendments, CAPA numbers.
- State the effectiveness check. When and how you'll verify the fix held — usually an internal audit at 90 or 180 days.
- Commit to a timeline. Realistic, not aspirational.
The fastest path to a closed 483 is to treat every cybersecurity observation as both a documentation fix and a process fix. Inspectors come back. Process fixes are what survive a re-inspection.
What to do before the next inspection
If you make connected medical devices and you haven't had an FDA inspection since QMSR took effect, you are operating on borrowed time. The three highest-leverage things to do this quarter:
- Audit your DHF for SBOM and threat model freshness against every product currently on the market. A premarket SBOM from 2023 that hasn't moved is a finding waiting to happen.
- Stand up a documented postmarket vulnerability process that ties CVE intake → risk assessment → complaint system → CAPA. This is the 820.35(a) playbook.
- Walk through your complaint handling SOP with a cybersecurity scenario in the room. If the SOP can't accept "the device behaved suspiciously after a network event" as an intake, rewrite it.
Frequently asked questions
Is a Form 483 the same as a Warning Letter?
No. A 483 is a list of observations from an on-site inspection. It is not a final agency action. A Warning Letter is the escalation that follows when the FDA decides your 483 response was inadequate or the observations were serious enough on their own. Warning Letters are public; 483s are not, though they are FOIA-able.
Can cybersecurity actually be cited on a 483?
Yes. Since QMSR took effect on February 2, 2026, inspectors have explicit clauses (notably 820.35(a) for postmarket activities, plus ISO 13485 clauses incorporated by reference) to cite cybersecurity-related gaps as quality system observations. Cybersecurity is no longer a premarket-only conversation.
How long do I have to respond to a 483?
The FDA expects a written response within 15 business days. A response submitted in that window is considered before any decision to escalate to a Warning Letter. Responses after that window still matter, but the agency is no longer obligated to consider them in the escalation decision.
What's the difference between a 483 cybersecurity observation and a deficiency letter?
A 483 follows an on-site inspection of your facility and cites QMSR clauses. A deficiency letter is issued during desk review of a premarket submission and cites the premarket cybersecurity guidance plus Section 524B. Different stage, different reviewer, different clock — but the underlying expectations overlap heavily.
Does the FDA inspector need cybersecurity training to write these observations?
The FDA has been training investigators on cybersecurity since the run-up to QMSR, and many districts now have at least one investigator with a software/cyber background. In practice, inspectors don't need to be penetration testers to cite gaps in documentation, process, or postmarket monitoring — those are quality-system observations that any trained investigator can write.
Got a 483 with cybersecurity observations?
The 15-day clock is the only clock that matters right now. We've drafted responses to cybersecurity-flavored 483 observations, prepared manufacturers for follow-up inspections, and closed out CAPAs that the FDA accepted on the first round.
- See the related work on QMSR and cybersecurity and cybersecurity as a QMS requirement.
- Or book a discovery call and we'll triage your 483 under NDA within 24 hours.