Clear answers for 510(k), eSTAR, SaMD/AI, LED, QMSR 2026, OTC & MoCRA

Yes—most 510(k)s require at least one legally marketed predicate device to support a substantial equivalence comparison. If you cannot identify a defensible predicate (same intended use and similar technological characteristics), a different pathway (such as De Novo) may be more appropriate.

• A strong predicate aligns on intended use, indications, and core technology.
• If differences raise new questions of safety/effectiveness, the predicate strategy may need revision.

eSTAR is the FDA’s electronic submission template that standardizes how 510(k) content is organized and submitted. It helps reduce administrative errors by prompting required elements, enforcing structure, and making it easier for FDA reviewers to navigate the file.

• Designed to improve completeness and consistency at submission.
• Still requires the same technical evidence—eSTAR is the format, not the “approval shortcut.”

Timing depends on testing scope and iteration, but many projects take several months end-to-end. Preparation often takes 2–6+ months (especially if standards testing is needed), and FDA review includes an initial acceptance screen plus substantive review that may involve additional information requests.

• The biggest schedule driver is usually testing (lab queues + retesting if scope changes).
• Clear claims + a strong predicate strategy reduce review friction.

Testing is driven by intended use, risk, device technology, and recognized standards. Many devices require some combination of bench performance testing, biocompatibility (when patient-contacting), electrical safety/EMC (for powered devices), software verification/validation (for software-enabled devices), cybersecurity (when networked), and usability/human factors (when user interaction can impact safety).

• Test plans should be built to match your claims—over-claiming often triggers additional testing.
• Standards selection and justification are a core part of a defensible submission.

Software is generally considered Software as a Medical Device (SaMD) when it performs a medical function on its own (e.g., analyzes, diagnoses, or drives clinical decisions) without being part of a specific hardware medical device. If your software only supports general wellness, administrative tasks, or non-medical functions, it may not be SaMD—your claims and intended use language are the deciding factors.

• The same core software can fall in or out of scope depending on how you market it.
• Clinical performance evidence may be needed when software drives or significantly influences decisions.

Sometimes. If an LED product is intended to diagnose, treat, mitigate, or prevent disease—or makes medical claims—it may be regulated as a medical device and require the appropriate pathway (often 510(k)). If it is positioned strictly for general wellness/cosmetic purposes with non-medical claims, it may have reduced regulatory burden, but the line depends on your intended use, labeling, and marketing.

• Medical claims (acne treatment, disease outcomes) increase the likelihood of device regulation.
• Claim strategy and labeling are as important as the hardware specs for regulatory scope.

Sometimes—but only if you can justify that performance and safety are adequately supported through recognized standards, prior testing, literature, and/or comparative data. In most cases, at least some bench verification is expected, especially when new materials, new energy delivery, or new core functions are introduced.

• Bench testing is often the fastest “proof” for equivalence when technology differs.
• If you remove testing, you usually increase rationale burden—and risk FDA questions.

A Traditional 510(k) is the standard route for new devices or substantial changes. A Special 510(k) is typically used for certain modifications to your own legally marketed device when you can leverage design controls and risk management to support equivalence. Eligibility depends on the change type and FDA expectations.

• Special 510(k) is not a shortcut for “big” changes.
• Device type, change type, and documentation readiness determine fit.

Common triggers include missing required sections, unclear indications/claims, weak predicate rationale, gaps in testing rationales, inconsistent labeling, incomplete software/cybersecurity documentation, and insufficient performance data to address differences from the predicate.

• RTA = administrative completeness problems.
• AI = technical gaps that prevent FDA from completing substantive review.

FDA does not “approve” a QMS as part of 510(k) review, but you should have design controls and risk management in place because they directly support device safety and submission defensibility. Also, you must be ready for post-clearance Quality System inspections and compliance expectations.

• Design controls help prove you built what you say you built.
• Inspection readiness becomes important as you scale manufacturing and distribution.

QMSR is FDA’s Quality Management System Regulation update that aligns 21 CFR Part 820 more closely with ISO 13485 concepts. It matters because it changes how companies demonstrate quality compliance and inspection readiness, including stronger expectations around risk management and QMS processes.

• If you’re already ISO 13485-aligned, the transition is usually smoother.
• Gaps typically show up in process rigor, risk integration, and documentation discipline.

If your device connects to networks, exchanges data, has remote updates, or could be exposed to unauthorized access, you should expect cybersecurity expectations. Documentation often includes a threat model, SBOM where applicable, security controls, testing evidence, and a plan for vulnerability management.

• “Not cloud-connected” doesn’t always mean “no cyber scope.”
• Start early—cyber requirements can change architecture decisions.

Often yes—if your claims stay in the cosmetic/general wellness lane and avoid diagnosing, treating, mitigating, or preventing disease. The deciding factors are your intended use, labeling, and marketing. Crossing into treatment claims (e.g., wound healing, pain, disease outcomes) can trigger device regulation.

• Claim strategy is a regulatory lever—use it intentionally.
• Align claims with what your evidence can truly support.

OTC drugs typically follow the monograph system (where applicable) rather than 510(k). Compliance often centers on active ingredients, labeling (Drug Facts), manufacturing controls, and—when required—drug listing and NDC/labeler requirements. The right path depends on whether you are monograph, NDA, or otherwise.

• “OTC compliant” is usually a labeling + formulation + manufacturing question.
• Devices and drugs can overlap—combo analysis matters for some products.

MoCRA (Modernization of Cosmetics Regulation Act) introduces requirements such as facility registration, product listing, adverse event reporting, safety substantiation, and certain labeling/recordkeeping expectations. Applicability and timelines depend on your role (manufacturer, packer, distributor) and product specifics.

• Start with: who manufactures/labels, where it’s made, and what claims are made.
• Safety substantiation and complaint/AER handling are common gap areas.

Start with what you can actually support with testing and what your predicate(s) have already established. Intended use and indications drive classification, testing scope, and review friction—overly broad language is one of the fastest ways to create more testing and longer review cycles.

• Align claims to evidence and standards—not marketing ambition.
• Good intended use is specific enough to be defendable, broad enough to be commercially useful.