FDA Cleared vs Approved: What the Difference Means
Two words, two regulatory pathways, two very different evidence burdens — and confusing them is a liability risk.
Blake Aber · Predicate Ventures
People use "FDA cleared" and "FDA approved" as if they mean the same thing. They do not. The two terms describe separate legal pathways, each with its own evidence standard, its own risk tier, and its own set of claims a company is allowed to make.
If you build or buy software that touches patient care, the distinction matters. It determines what you can say in marketing, what a plaintiff's attorney can argue in court, and how much validation you owe before a model goes live.
The two pathways, in plain terms
The FDA regulates medical devices by risk. Software can be a device. A diagnostic model, a triage tool, an algorithm that flags a scan for review — all of these can fall under device regulation.
Clearance comes through the 510(k) process. A company shows its device is "substantially equivalent" to a device already legally on the market, called a predicate. The bar is comparison, not fresh proof of safety and effectiveness from scratch.
Approval comes through the premarket approval (PMA) process. This applies to higher-risk, Class III devices. The company must submit clinical evidence that the device is safe and effective on its own terms. There is no predicate to lean on.
Most software that reaches the market is cleared, not approved. The 510(k) route is faster and cheaper, which is why it dominates. But "cleared" is a weaker claim than many buyers assume.
Why the word choice is a legal matter
Saying a product is "FDA approved" when it was only cleared is not a marketing flourish. It is a misstatement of regulatory status, and the FDA treats it as such.
The agency has issued warning letters over exactly this. A company that overstates its clearance invites enforcement. It also hands a litigator a clean argument: the product was sold under a false regulatory claim.
The reverse mistake happens too. Teams describe an approved device as merely cleared and understate the evidence behind it. Either way, precision protects you.
What each term lets you claim
A cleared device can be marketed for the uses described in its 510(k) submission. Step outside that intended use and you are promoting an unapproved application, which carries its own exposure.
An approved device carries claims backed by the clinical data in its PMA. Those claims are narrower and more specific because they were tested.
Neither status is a blanket endorsement. The FDA does not bless a product in the abstract. It authorizes a specific device for a specific intended use. Marketing copy that drifts past that boundary is where trouble starts.
The AI wrinkle
Traditional device review assumes a fixed product. The device that gets cleared is the device that ships, and it stays the same.
Machine learning breaks that assumption. A model that retrains on new data changes after clearance. The FDA has acknowledged this with its framework for predetermined change control plans, which let a manufacturer describe in advance how a model may update without triggering a new submission.
That framework helps, but it raises the evidence bar. If your model learns in the field, you have to show the regulator how you will monitor it, when you will intervene, and how you will prove the updated version still performs. The documentation burden grows with the model's autonomy.
This is the gap between a static tool and a learning system. The law was written for the former. Teams deploying the latter carry the cost of the mismatch.
Evidence is the real product
Clearance and approval are both outcomes of evidence. The question a regulator asks, and the question a court asks later, is the same: can you show your work?
That means documented validation. Test sets that reflect the population the model will see. Performance measured across subgroups, not just in aggregate. A record of what the model does when it fails, and what the human operator is supposed to do in that moment.
Aggregate accuracy hides problems. A model that performs well overall can perform badly for a subgroup that was underrepresented in training. If that subgroup is a protected class, the failure is not only a safety issue. It is a discrimination claim waiting for a plaintiff.
The evidence you keep before launch is the evidence you will rely on after something goes wrong. Build it as if it will be read aloud in a deposition, because it may be.
Liability does not stop at the FDA door
Regulatory status is a floor, not a shield. A cleared or approved device can still be the subject of a product liability suit. Clearance does not preempt most state tort claims.
So the clinical question and the legal question converge. Did the model perform as described? Was the described use honest? Did the operator have the information to catch an error? A clean validation record answers all three.
Privacy sits alongside this. The data that trains and runs a clinical model is often protected health information. Mishandle it and you face a separate body of law with its own penalties, independent of device status.
What this means before you deploy
Start by knowing which pathway your product used, or needs to use, and say so accurately in every document a customer or regulator will read.
Match your claims to your evidence. If you have not tested a use, do not promote it. If a model changes over time, have a plan for how you prove it still works.
Validate against the population you will actually serve, and keep the subgroup results. The failure modes you document now are the defenses you will have later.
The difference between cleared and approved is a difference in how much you proved. In a field where the law is strict and the harm is personal, that difference is the whole point.