The eSTAR (electronic Submission Template and Resource) is an interactive PDF form that guides you through building a medical device premarket submission in the same structure FDA reviewers use. It has been mandatory for all 510(k) submissions since October 1, 2023, and for De Novo requests since October 1, 2025. You complete the form, attach your supporting documents, and upload the package through the FDA CDRH Portal.

The form is dynamic. Fields appear or disappear based on your earlier answers, so selecting a Traditional, Abbreviated, or Special 510(k) changes which sections you are asked to complete. FDA also publishes separate versions for in vitro diagnostic (IVD) and non-IVD devices.

One point is worth understanding up front: the eSTAR checks that your submission is complete, not that it is convincing. Its built-in verification helps you get the package in the door, but clearance still depends on whether your evidence demonstrates substantial equivalence.

A little setup saves a lot of rework:

• Download the current version from the FDA eSTAR Program page. FDA updates it periodically, and an outdated version can trigger requests for more information.
• Choose the right version for your device, IVD or non-IVD.
• Use a full PDF editor. FDA recommends Adobe Acrobat Pro or Foxit PDF Editor. The free Adobe Reader does not support the form and will display a warning.
• Build a parallel outline first. Gathering and checking your content in a shared document or spreadsheet is easier than working inside a dynamic PDF; then you transfer it in.

Administrative information

This opening section captures your submission type, applicant and correspondent details, establishment registration, and contacts. The premarket cover sheet (FDA Form 3514) is built in, so you complete it inside the form rather than as a separate file.

Device description

Describe what the device is, what it does, its components and materials, and how and where it is used. Write it as if the reviewer has never seen the product. Highly technical or internal terminology is a common cause of clarification requests, so keep the language plain.

Indications for use

The Indications for Use statement (FDA Form 3881) is integrated here. Keep the wording tight and consistent with your predicate, your labeling, and the evidence in the file. If the claim goes further than your testing supports, FDA will notice.

Classification

Provide the product code, regulation number, device class, and review panel. Classification anchors the rest of the submission, so confirm it against the FDA product classification database before you build the file.

Predicate device and substantial equivalence

Identify your predicate and compare indications and technological characteristics, ideally in a table. Where a difference exists, state it plainly and connect it to the supporting evidence. A material difference may call for biocompatibility data, a software change may call for software and cybersecurity documentation, and a performance difference may call for standards-based or clinical testing. This comparison is the heart of a 510(k).

Consensus standards and declarations of conformity

List the FDA-recognized standards you are conforming to. As you add standards, the form can generate the Declaration of Conformity for you.

Labeling

Include your proposed labels, instructions for use, and packaging labeling. Every labeling claim needs to line up with your indications for use and your testing.

Biocompatibility

For patient-contacting devices, the endpoints you need are driven by the nature and duration of contact you select, and the form expands the required evaluations accordingly. FDA expects a biocompatibility evaluation that ties results to the device use and risk, not a stack of test certificates on their own.

Sterility, shelf life, and stability

If the device is supplied sterile, include the sterilization method and validation, the sterility assurance level, packaging validation, and the aging or stability data that support your shelf life.

Software and firmware

For devices that contain software, this section holds your software documentation. The amount required scales with the device risk, following FDA guidance titled Content of Premarket Submissions for Device Software Functions, which sets a Basic or Enhanced documentation level. Typical contents include a software description, architecture, requirements, verification and validation, and a traceability analysis, aligned with IEC 62304. First-time filers often underestimate how complete this section must be. If you are assembling these documents from scratch, the DIY Software Kit templates and software validation training map directly to what this section asks for.

Cybersecurity and interoperability

For connected devices, this has become one of the most scrutinized sections, and thin documentation here is a frequent reason submissions are placed on hold. Structure your content around the categories in FDA's current premarket cybersecurity guidance, including a threat model, a software bill of materials, security architecture, and cybersecurity risk management. The DIY Cybersecurity Kit covers these artifacts.

EMC, electrical, wireless, and thermal safety

Provide the test reports that demonstrate electrical safety, electromagnetic compatibility, wireless coexistence where applicable, and thermal safety, generally against recognized standards.

Performance testing

This is the evidence behind your substantial equivalence claim, organized into non-clinical (bench), animal, and clinical testing as applicable. A human factors subsection sits here for devices where use-related risk needs to be addressed.

References and administrative documentation

The references section holds any literature you cite. The administrative documentation section collects the remaining forms and statements, including the truthful and accurate statement (now built into the form), the 510(k) Summary or Statement, and financial certification or disclosure. For a De Novo request, a Benefit, Risks, and Mitigation Measures section also applies.

The completeness check

Before you submit, the form runs a verification that flags empty required fields and missing attachments. Passing it means your package is complete enough to enter review. It does not mean the submission will be cleared. If you file an incomplete form, FDA notifies you and places the submission on hold until you upload a corrected version.

Common first-time filer mistakes

• Treating the completeness check as a quality check. It confirms nothing is missing, not that your evidence is strong.
• Using Adobe Reader instead of a full PDF editor.
• Reusing an old version of the form instead of downloading the current one.
• Writing indications for use that do not match the predicate or the labeling.
• Submitting thin software or cybersecurity documentation.
• Answering a nuanced situation with a bare yes or no instead of adding a short explanatory attachment.

How to prepare before you build the file

Most of the work happens before the PDF. A submission-ready quality system, complete design documentation, and a clear substantial equivalence argument are what actually fill the sections. Pull together your device description, your risk management file (ISO 14971), your software and cybersecurity documentation, and your test reports first. Teams that keep these current inside their quality management system spend far less time wrestling with the form. Building the eSTAR template is the last step, not the first. If you want structured guidance across the whole process, GrassrootsDX offers software device teams a SOAR training program that walks through these requirements.