eSTAR Software: What It Is, How It Differs from FDA’s Template, and When You Need More Than the Free PDF

Overview

This section helps you decide whether the FDA's eSTAR offering is a downloadable application your team can plug into an authoring and governance workflow, or simply an interactive template you must integrate into existing processes. The FDA provides an interactive PDF called the Electronic Submission Template and Resource (eSTAR) rather than a multi-user application; see the FDA eSTAR program page for the template and current guidance.

That distinction — template versus software — matters operationally for regulatory affairs leads, quality teams, and engineering document owners. These roles coordinate content, reviews, and submission timing across functions, and the template's single-user PDF design does not support that workflow natively.

The eSTAR template standardizes submission structure for 510(k) and De Novo requests. It asks structured questions, triggers conditional fields, and runs built-in completeness checks intended to reduce Refuse-to-Accept (RTA) holds. What it does not provide is collaboration features, version history, audit trails, or direct integration with quality management or product lifecycle systems. Teams that need multi-contributor coordination, governance, and traceability typically evaluate third-party workspaces that complement the FDA template rather than replace it.

This guide targets regulatory affairs leads, regulatory operations managers, quality systems leads, and engineering documentation owners scoping an eSTAR-based submission workflow. It explains what the template does and does not do, how to choose the correct portal path, preflight considerations, and when third-party tooling may be worth the investment.

---

FDA eSTAR template vs third-party eSTAR software

The core question most teams face is not whether to use the eSTAR template — for covered submission types, use is required or strongly expected — but whether the template alone is sufficient for their operating environment.

The FDA eSTAR template is a structured, interactive PDF that enforces field-level completeness and conditional routing for the chosen submission type. It is maintained by FDA and available from the eSTAR program page. For a small, single-contributor team preparing a straightforward 510(k) with a clear predicate, the template alone may be sufficient. The template does not, however, manage concurrent authoring, provide native version history, support comment threads, or enforce section ownership across contributors.

Third-party tools marketed as "eSTAR-supporting workspaces" address those coordination gaps. They typically offer controlled draft environments where multiple contributors can work against the same version, mapped section ownership and review routing, comment and approval workflows with traceability, and exportable QA records. Some integrate with enterprise file systems such as SharePoint, Box, or Google Drive. These tools operate alongside — not instead of — the FDA template; the final submission still requires a completed eSTAR PDF.

The decision matrix below helps you evaluate process fit. Score three or more "third-party" triggers and the operational cost of managing the template alone is likely material.

This matrix evaluates process fit, not regulatory compliance. The eSTAR template enforces completeness of required fields, but regulatory soundness — adequate justification, appropriate predicates, and sufficient performance evidence — remains the submitter's responsibility regardless of which workflow approach they use.

---

Where eSTAR applies: submission types, centers, and templates

eSTAR currently applies to 510(k) premarket notifications and De Novo requests submitted to FDA's Center for Devices and Radiological Health (CDRH). PMA submissions follow a different process and are not covered by eSTAR in the same way. Consult the 510(k) program page and the De Novo program page for submission-type requirements.

Within eSTAR, there are two template variants: one for in vitro diagnostic (IVD) devices and one for non-IVD devices. The templates differ in section structure, conditional branching for performance testing, and expectations around analytical and clinical evidence. Selecting the wrong variant forces a restart, so confirm device classification before authoring begins rather than mid-cycle.

For devices with components regulated by the Center for Biologics Evaluation and Research (CBER) — such as certain combination products or some IVD tests — routing and portal mechanics may differ from a straightforward CDRH-reviewed 510(k). Clarify lead-center designation early, as it affects portal selection and how sections should be populated. When classification or lead-center assignment is ambiguous, a Pre-Submission (Q-Sub) is the appropriate mechanism to get written clarity before committing to a template and portal path.

---

System and IT requirements to complete eSTAR

The eSTAR interactive PDF requires Adobe Acrobat or Adobe Reader. Not all PDF viewers render interactive fields and embedded JavaScript correctly, and using a non-Adobe viewer is one of the most common sources of incomplete or corrupted submissions. Consult the FDA eSTAR program page for currently recommended Adobe versions and test the template in your corporate environment before authoring begins.

Because the PDF is single-user by design, only one person can edit it at a time. Simultaneous edits risk silent overwrites with no audit trail to identify which version is current. A common mitigation is to designate a single file owner who integrates contributions submitted via separate documents or structured forms, then consolidates them into the eSTAR. This handoff process should be defined explicitly in your document control plan, not improvised during final assembly.

Enterprise IT policies that restrict JavaScript execution, apply locked-down PDF security profiles, or enforce unusual macro permissions can prevent the template from functioning even on a supported Adobe build. Test the template under your organization's desktop policy and IT security configuration before the preflight stage to avoid discovering incompatibilities close to a submission deadline.

---

Portals and submission paths: CDRH Portal vs ESG

Two FDA portal paths are commonly used to transmit a completed eSTAR file: the CDRH Portal and the Electronic Submission Gateway (ESG). The CDRH Portal is the more commonly used path for 510(k) and De Novo eSTAR submissions. It supports direct upload of the eSTAR PDF plus supporting attachments, provides an acknowledgment of receipt, and routes submissions into CDRH review tracking.

ESG is FDA's broader submission infrastructure, originally focused on eCTD submissions for pharmaceuticals and biologics. Some CDRH submissions can route via ESG, but ESG requires separate account setup and technical configuration that can add lead time if not managed in advance. Consult ESG documentation for account prerequisites and file format expectations specific to device submissions.

If routing is unclear — combination products, ambiguous classification, or unusual device mechanics — confirm the portal path with your FDA project manager or via a Pre-Submission (Q-Sub) before finalizing the package. Submitting via the wrong portal after completing a full package creates avoidable delays that cannot be resolved quickly once the submission clock is in question.

---

Operational mechanics: attachments, sizes, and naming

The eSTAR template accepts supporting documents as either embedded attachments within the PDF or as separate accompanying files, depending on attachment type and section. Embedded attachments are effectively a one-time insertion: replacing an embedded file requires careful handling and retesting to avoid corrupting the reference or triggering completeness check failures. The practical rule is to finalize supporting documents before embedding them, not after.

Attachments submitted alongside the eSTAR should use consistent internal naming that mirrors eSTAR section identifiers and includes version identifiers. A file named generically (for example, "TestReport_Final.pdf" with no section reference or version string) creates unnecessary reviewer friction and slows technical screening. Establish a naming convention at the start of the project and enforce it before assembly.

Portal size constraints vary by submission type and are documented on the respective portal guidance pages. Very large test reports, clinical datasets, or imaging files may need to be split, compressed, or transmitted via a separate mechanism. If your total package approaches the portal's documented limit, contact FDA eSTAR support before submission rather than attempting to exceed limits and risk a rejected transmission.

---

Preflight validation: the eSTAR readiness checklist

Running a systematic preflight is the most reliable way to prevent technical screening holds and avoid delaying the review clock. The eSTAR template's completeness indicators are useful but do not catch every condition that can cause a technical problem on receipt — particularly issues involving attachments, portal routing, and consistency across sections. Work through the checklist below sequentially; later items can surface issues introduced by earlier steps.

eSTAR preflight checklist

• [ ] Template version confirmed against the current version on the FDA eSTAR program page; no mid-cycle version change is pending
• [ ] Correct template variant selected: IVD or non-IVD, matched to the confirmed device classification
• [ ] All required sections show complete status within the eSTAR template's internal progress indicators
• [ ] Conditional sections triggered by earlier answers have been reviewed and completed where required
• [ ] All embedded attachments open correctly when tested in Adobe Acrobat (not a lightweight or browser-based viewer)
• [ ] Separate accompanying files are named consistently, referenced accurately in the relevant eSTAR sections, and present in the submission package
• [ ] Submission package total size is within the documented limit for the chosen portal (CDRH Portal or ESG)
• [ ] Portal account credentials and submission routing confirmed for the correct center (CDRH vs CBER lead)
• [ ] Device identifier fields, applicant information, and predicate citation are consistent across all sections and attachments
• [ ] Internal QA review completed and sign-off documented before transmission

Treat this checklist as the last technical gate, not the only quality gate. Completeness in the template does not equal regulatory adequacy. Maintain separate internal QA steps to assess the strength of claims, predicate rationale, and performance evidence independent of whether every field is populated.

---

Placing cybersecurity artifacts (SBOMs, testing, vulnerabilities)

Cybersecurity content expected in premarket submissions is described in FDA's 2023 cybersecurity guidance for premarket submissions. That content should map to specific eSTAR sections rather than being consolidated into a single attached report with a brief narrative summary in the template fields.

An SBOM typically belongs in the software documentation section alongside architecture documentation and a software development lifecycle summary. Vulnerability assessments and threat modeling fit within cybersecurity risk management sections. Penetration test reports and detailed test results should be supporting attachments referenced from the narrative sections, not substitutes for it. Reviewers expect substantive narrative in the eSTAR fields, with attachments serving as underlying evidence rather than carrying the argument.

Avoid duplicating detailed tables across multiple sections. Duplication creates inconsistency risk if one copy is updated and others are missed — a common issue in multi-contributor workflows without a single file owner. Aim for a self-sufficient cybersecurity narrative in the relevant sections that cross-references one authoritative attachment for detailed data.

Even devices without network connectivity can trigger cybersecurity questions if they contain software components or user interfaces. Provide a concise rationale for why specific cybersecurity controls do or do not apply rather than leaving conditional fields blank or entering a one-line disclaimer.

---

AI/ML and SaMD specifics: where PCCPs and algorithm details go

Predetermined Change Control Plans (PCCPs) for machine learning-enabled devices are described in FDA's PCCP guidance. PCCP content typically belongs in device description and software documentation sections of eSTAR, with relevant elements also referenced in risk management sections when proposed changes affect safety or performance.

Algorithm performance evidence — validation datasets, performance metrics, and subgroup analyses — belongs in the performance testing section. Present it with clear statistical methodology and explicit descriptions of the training, tuning, and test sets used, including any demographic or site stratification relevant to generalizability.

A key operational challenge for AI/ML submissions is the snapshot problem: eSTAR captures the device at a point in time while cloud-connected models may update after clearance. PCCPs manage post-clearance changes within agreed boundaries; any update outside those boundaries requires a new submission. For this reason, define PCCP scope carefully during initial eSTAR authoring rather than retrofitting boundaries after clearance creates pressure to expand them.

---

PreSTAR and Q-Sub: getting feedback before you commit

PreSTAR is a draft eSTAR that can be shared with FDA as part of a Q-Sub meeting request. It allows reviewers to provide feedback on content and structure before the formal submission clock starts, reducing the risk of substantive deficiency letters on novel or complex submissions. Be aware that any favorable feedback from FDA refers to the draft content provided — deviations in the final submission should be clearly justified, ideally in a cover note or dedicated section.

The broader Q-Sub program supports Pre-Submissions that do not use the PreSTAR format and is appropriate for clarifying regulatory path, testing plans, predicate selection, or cybersecurity scope before authoring is complete. Content developed for Q-Subs or PreSTARs can be reused in the final eSTAR, but track changes carefully so you can explain discrepancies if a reviewer compares the two.

Maintain a log that records what was shared with FDA, what FDA commented on, and what changed and why between the pre-submission and the final eSTAR. That log provides useful traceability if reviewers ask why the final submission differs from prior pre-submission material, and it is good practice for the design history file regardless.

---

IVD vs non-IVD differences you should plan for

Choosing between the IVD and non-IVD templates shapes your design history file structure and internal document planning from the start. The IVD template includes explicit sections for analytical performance — precision, linearity, interference, and reference intervals — and dedicated structures for comparator studies and clinical performance data. These sections are not present in the same form in the non-IVD template and cannot be meaningfully improvised after the wrong template has been partially completed.

The non-IVD template is more modular across topics such as biocompatibility, sterility, EMC, software documentation, and electrical safety. It will not automatically prompt for IVD-specific analytical validation content, which means an IVD device filed on the wrong template will appear structurally complete but will be substantively incomplete for the analytical evidence reviewers expect.

Confirm the primary regulatory classification using the FDA product classification database before template selection or pursue a Q-Sub if classification is ambiguous. The cost of classification uncertainty is much lower at the Q-Sub stage than at technical screening.

---

Handling eSTAR version changes without rework spirals

When FDA releases a new eSTAR version during development, the team needs a deliberate decision rather than a reactive one. Freeze on the current version for project stability when the submission is weeks from transmission and the changes address minor label updates or formatting clarifications with no substantive content impact. Migrate to the new version when changes reflect updated regulatory expectations — new cybersecurity prompts, revised software questions, or additional performance data requirements — because an older structure is likely to generate review questions regardless of how carefully the existing fields are completed.

Use the template release notes on the FDA eSTAR program page to evaluate the scope of changes. Document your decision in a change log that records which eSTAR version was used, the rationale for freezing or migrating, and preserve a copy of the template version used alongside the submission package. That copy matters for traceability if questions arise during review or in a subsequent supplement.

---

Governance, document control, and Part 11 relevance

The eSTAR PDF is not an electronic records system and does not produce the timestamped, attributable audit trails that 21 CFR Part 11 addresses. Whether Part 11 applies to your eSTAR authoring process depends on how your QMS scopes electronic records and which systems create those records. The template itself is not an FDA-regulated electronic records system — it is a submission format.

Regardless of Part 11 scope, treat the eSTAR PDF as a controlled document from initiation: store it under version control, limit editing access to authorized contributors, apply defined review and approval workflows, and retain retrievable records of contributions and approvals. Attachments embedded or transmitted alongside the eSTAR should themselves be controlled documents with traceable revision histories. An uncontrolled attachment in a controlled submission package creates a gap that surfaces during internal audit or external review.

In multi-site or OEM–ODM scenarios, establish formal agreements on document delivery formats, revision freeze dates, and responsibility for content accuracy before authoring begins. Governance gaps typically surface during preflight when a file owner discovers that an OEM-supplied attachment is an earlier revision than the narrative references — and the OEM's document control cycle may not be on the same schedule as the submission deadline.

---

Common pitfalls and troubleshooting patterns

The issues below recur frequently enough across eSTAR submissions that they are worth treating as a standing checklist rather than one-time reminders. Most are preventable with defined process steps and the preflight sequence described above.

• Using a non-Adobe PDF viewer for authoring or final review; interactive fields and completeness checks may not render or function correctly.
• Concurrent editing by multiple contributors without a custody protocol; the last save overwrites earlier work with no record of what changed.
• Selecting the wrong template variant (IVD vs non-IVD), which forces a restart and can delay the project by days depending on how far authoring has progressed.
• Conflating template completeness with regulatory soundness; a fully completed template is a minimum threshold, not evidence of submission quality.
• Bundling all cybersecurity documentation into a single attached report rather than providing substantive eSTAR narrative with attachments serving as supporting evidence.
• Inconsistency between PreSTAR or Q-Sub content and the final eSTAR without documented justification for the differences.
• Transmitting via the wrong portal; confirm CDRH Portal vs ESG routing before finalizing the package.
• Embedding attachments before documents are finalized; embedded files are difficult to replace cleanly without retesting the full package.
• Skipping the template version check; evaluate new versions against your submission timeline before assuming the current template is still current.
• Missing governance controls for multi-party contributions; confirm attachment revisions match the narrative before final assembly.

---

Key sources and how to keep your process current

The FDA eSTAR program page is the authoritative source for current IVD and non-IVD templates, release notes, and links to associated guidance documents. Check it at the start of each new project and again before the preflight stage to confirm the version you are working on has not been superseded.

For cybersecurity content expectations, consult FDA's 2023 cybersecurity guidance for premarket submissions. For AI/ML and PCCP placement, use the FDA PCCP guidance as the authoritative reference for what belongs in device description, software, and risk management sections.

Setting a quarterly calendar reminder or an FDA guidance alert for updates to Medical Devices pages helps you catch template or guidance changes before they become mid-development surprises. If your team manages multiple active programs, a shared log of current template versions and recent FDA guidance updates reduces the risk of one program carrying forward an outdated assumption that was already corrected for another.

Deciding whether to add tooling to your eSTAR workflow. If your review flagged three or more third-party triggers in the decision matrix above, the coordination overhead of the single-user PDF is a real operational risk — not a hypothetical one. A workspace that maintains controlled sequence state, shared section ownership, and traceability across contributors addresses the gaps the template leaves open. Assyro's eCTD submission workspace applies that model to regulated submission environments, with automated readiness checks that run while content is drafted rather than at the end. If you want to estimate the financial impact of tightening your submission cycle before committing to a tool evaluation, the regulatory ROI calculator lets you configure your baseline and see annualized impact figures you can bring to a resourcing conversation.