01
Device makers after a vendor change
A codebase built by another vendor, with records to bring up to date.
Healthcare / Sustaining Engineering
Medical device software sustaining engineering
Clearance is the start of a device's life on the market, not the end of the software work. Agnotic Technologies keeps released device software and companion apps safe and current: problem fixes, change assessments, operating system and SOUP updates, and cybersecurity patches, all inside your quality system.
After clearance
The years a device spends on the market
Change assessment
Every change checked against FDA's questions
Patch cadence
Regular releases plus urgent fixes
Trusted by global innovators
Industry Overview
What is medical device software sustaining engineering?
Medical device software sustaining engineering is the lifecycle work that keeps released device software and its companion apps safe and on the market: problem resolution, assessing whether each change needs a new FDA submission, operating system and SOUP updates, cybersecurity patches and SBOM upkeep. Agnotic Technologies provides these lifecycle services inside the manufacturer's quality system.
Industry Challenges
What breaks after a device software release?
The problems we see most often when a manufacturer hands us a device that is already on the market.
A mobile operating system update changes Bluetooth or background behaviour, and the companion app stops syncing.
A third-party library the device depends on reaches end of support, and nobody listed it as SOUP.
A vulnerability is published for a component, and the SBOM is too old to say whether the device uses it.
A one-line bug fix ships with three features, so a simple change now needs a full impact assessment.
Regression evidence is rebuilt by hand for every release.
The original team has gone, and the design history no longer matches the code.
Old app versions are still installed, with no plan for when support ends.
Change assessment
Does this software change need a new 510(k)?
Our change assessment checklist. It records the first questions from FDA's 2017 software change guidance and the evidence we prepare for each change type. The decision belongs to your regulatory team; we prepare the analysis and the verification evidence.
| Change type | First questions to answer | Verification evidence we prepare | New submission likely? |
|---|---|---|---|
| Security patch to a third-party component | Is it made solely to strengthen cybersecurity, with no other impact on the software or device? | Vulnerability record, SBOM change, regression tests on affected functions | In many cases no, once the analysis confirms no other impact |
| Bug fix that restores cleared behaviour | Does it only return the software to the specification of the most recently cleared device? | Defect record, root cause, tests proving the specification is met | Usually no, after an impact analysis |
| Mobile OS compatibility update | Does it change a risk control or how a clinical function performs? | Compatibility test matrix per OS version and a risk file review | Depends on the risk analysis |
| UI text or workflow change | Could it create or change a hazardous situation or a use error? | Use-related risk review and usability evidence where needed | Depends on the risk analysis |
| New feature | Does it change the intended use, a clinical function or the risk profile? | Requirements, design and full verification for the feature | Likely |
| Algorithm retrain or new model version | Is it covered by an authorized PCCP and implemented as the plan describes? | The data, training and performance records the PCCP specifies | No, if inside the authorized PCCP; otherwise likely |
Our Approach
How should a manufacturer organise sustaining work?
Three habits that keep each release small, explainable and quick to assess.
Separate fixes from features
Fixes and patches ship in their own releases, so most of them answer the first two questions of the change assessment quickly and do not wait for feature work.
Keep SOUP and SBOM as live records
Every component, its version and its support status are tracked continuously, so a new vulnerability or an end-of-support notice becomes a ticket on the same day.
Plan end of support from the start
Each released version has a support window, a minimum OS version and a decommission plan that users and service teams know about.
Capabilities
What does our sustaining engineering service cover?
Lifecycle services for device software and companion apps, delivered under your procedures.
Problem resolution
Problem reports logged, investigated and classified for safety relevance, following the IEC 62304 process.
Change impact analysis
Each change assessed with the checklist above and the evidence attached for your regulatory team.
Regression automation
Automated tests on device rigs and phones, so each release reuses evidence instead of rebuilding it.
OS and SOUP watch
Upcoming mobile and embedded OS releases and component end-of-support dates tracked ahead of time.
Vulnerability management and SBOM
Component inventory kept current, new vulnerabilities triaged and fixes planned.
Patch releases
A regular release cycle for known issues and an out-of-cycle path for critical vulnerabilities.
Design history upkeep
Requirements, risk file, traceability and release notes updated with every change.
End of support
Version support windows, user notices and decommissioning of old app versions and services.
How It Works
How does a problem report become a released fix?
The path every change follows. Each step leaves a record your auditors can follow.
Log the problem report
From complaints, field logs, testing or a vulnerability notice, with the affected versions.
01
1
Investigate and classify
Reproduce, find the root cause and decide whether the problem is safety related.
02
2
Assess the change
Run the change assessment and record the regulatory decision your team makes.
03
3
Implement and verify
Fix, regression tests and any new verification the assessment calls for.
04
4
Update the records
Risk file, SOUP list, SBOM, traceability and labeling where affected.
05
5
Release in stages
Signed builds rolled out by group, with adoption of the new version monitored.
06
6
Close the report
Confirm the fix in the field and link the closure to the original report.
07
7
Engineering Stack
Which records and tools does sustaining work keep current?
We work in your tools where you have them, and set them up where you do not.
Lifecycle records
Software maintenance planProblem reports and change requestsTraceability matrixRelease notes
Security
SBOM in SPDX or CycloneDXVulnerability feedsThreat model updates
Testing
Automated regression suitesDevice test rigsPhone and OS version matrix
Release
Signed buildsStaged rolloutApp store and installer channels
Measured Impact
What should a sustaining program measure?
Measures we report to your quality and regulatory leads every release.
Open
Problems by safety class
Open problem reports and their age, split by safety relevance.
Patch
Fix latency
Time from a vulnerability notice to a released fix.
SOUP
Component currency
Components on a supported version, and those nearing end of support.
Spread
Version adoption
Share of devices and app installs on each supported version.
My Lauren Maternal Health Platform | Built by Agnotic
A HIPAA-ready maternal health platform enabling remote patient monitoring, care coordination, and personalized engagement from pre-pregnancy through postpartum.
Case Study
LERA Health: Women's Health App Platform
A women’s health product experience focused on guided care journeys, education, and compliance-aware workflows to support long-term engagement.
Case Study
Use Cases
Who hands sustaining engineering to us?
Manufacturers whose device is on the market and whose software still needs a team.
02
Startups after first clearance
A small team that needs to keep shipping fixes while building the next product.
03
Manufacturers with a growing portfolio
Several released products that each need patches and OS updates.
04
Companion app owners
Apps that must keep working through every new phone OS release.
05
AI-enabled device teams
Model updates run under an authorized PCCP.
06
Manufacturers retiring a product
End-of-support notices and decommissioning done in an orderly way.
Integrations
Which systems does sustaining work connect to?
The systems a change touches between the problem report and the release.
Change control and records
eQMS
Problem reports
Issue tracker
Field input
Complaint handling system
Builds and tests
Source control and CI
Release
App stores and update servers
Security input
Vulnerability databases
Compliance-First Development Services Backed by Global Standards
We build secure, scalable products designed for privacy, interoperability, and regulatory readiness from day one across every sector we serve.
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, and strict access controls.
Quality Management Systems
Ensuring consistent quality in software delivery and operational process optimization.
Our Edge
Why Global Leaders Choose Us
We combine deep technical expertise with industry-specific knowledge to deliver solutions that aren't just functional, but transformational.
Enterprise-Grade Security
We implement rigorous security protocols and compliance standards (HIPAA, GDPR, SOC2) across all industrial solutions to protect sensitive data.
High-Performance Scaling
Our architectures are built to handle massive data loads and user bases, keeping performance steady whether you're serving ten or ten million.
Accelerated Time-to-Market
Using our suite of internal tools and proven frameworks, we cut setup work so your first release reaches users sooner.
Embedded AI Integration
Beyond simple wrappers, we build deep-learning integrations and predictive analytics directly into the core of your industry-specific workflows.
Engagement Model
How does a lifecycle services engagement start?
We take over in stages, so nothing ships before the records are understood.
01
Scoping call
We review the device, its software versions in the field and your change control process.
02
Codebase and records audit
Build the code, compare it with the design history and list the gaps.
03
Maintenance plan
Release cadence, SOUP watch, patch path and support windows agreed with your quality team.
04
Steady releases
Fixes and patches shipped on the agreed cycle, with evidence attached.
05
Ongoing or handover
We keep running it, or hand it back to your team with the records current.
Facts and sources
Which rules shape changes to released device software?
Short facts behind our change assessment and patch process, each linked to its primary source.
A new premarket notification is required when a device already in commercial distribution is about to be significantly changed, including any change that could significantly affect its safety or effectiveness or a major change in its intended use.
Source: 21 CFR 807.81(a)(3) (eCFR)FDA's 2017 software change guidance says that in many cases a change made solely to strengthen cybersecurity is not likely to require a new 510(k), provided the manufacturer's analysis, verification or validation shows no impact on safety or effectiveness.
Source: FDA, Deciding When to Submit a 510(k) for a Software Change to an Existing Device (October 2017)When FDA authorizes a predetermined change control plan, the manufacturer may make the planned changes without a new marketing submission for each one, as long as they are included in and implemented according to the authorized plan.
Source: FDA, Predetermined Change Control PlansSection 524B of the FD&C Act requires cyber device sponsors to make postmarket updates and patches available on a reasonably justified regular cycle for known unacceptable vulnerabilities, and as soon as possible out of cycle for critical ones, and to provide a software bill of materials.
Source: 21 U.S.C. 360n-2 (FD&C Act section 524B), on govinfo.govThe Quality Management System Regulation became effective on 2 February 2026 and amends 21 CFR Part 820 to incorporate by reference ISO 13485, the international standard for medical device quality management systems.
Source: FDA, Quality Management System Regulation (QMSR)
Voice of success
We don't just build products; we forge lasting partnerships. See how we've helped industry leaders transform their vision into technical reality.
“I can clearly see how Agnotic has a unique way of handling end-to-end development. They are always active on quick chat and provide support quickly.”
Aaron Phelan
Founder, Benchmark
“Agnotic combines deep technical expertise with strong domain knowledge. They understand the business context, anticipate challenges, and make collaboration smooth and effective.”
John Pasmore
Founder, Latimer
“Agnotic is the best technical team we evaluated. Their engineering excellence made our work dramatically easier and allowed us to stay focused on what matters most for maternal care outcomes. They took full ownership of the technical execution, and we are always happy to continue working together.”
Kim Smith
Founder, My Lauren
Related services
Related device software services
This page covers the years after release. These pages cover building, submitting and supporting device software.
Medical device software development
Building device software, companion apps and connected platforms.
FDA SaMD compliance
Initial classification and premarket submission.
Medical device complaint handling software
Complaint intake and the reporting decisions that follow.
Medical device connectivity software
Device data flowing into clinical systems.
Software maintenance and support
Maintenance and support for applications outside the device.
IVD software development
Instrument and assay software for diagnostics makers.
More in Healthcare
More Healthcare Solutions
Explore other production-grade engineering platforms we deliver across healthcare.
Cross-Industry Reach
The Same Engineering Patterns, Across Other Industries
The technical patterns behind this platform translate naturally into adjacent verticals.
Frequently Asked Questions
Yes. We start with a codebase and records audit: we build the code, compare it with the design history and the SOUP list, and agree the gaps to close before the first release under our care.
Your regulatory team. We run the change assessment against FDA's software change guidance and prepare the analysis and verification evidence, so the decision is quick and documented.
We test beta OS releases before they ship, keep a phone and OS version matrix, and plan a compatibility release. The change still goes through the assessment, because a sync change can affect a risk control.
A predetermined change control plan is authorized with the marketing submission and lists planned changes, how they will be made and how their impact will be checked. Changes made within it do not need a new submission each time, which suits planned model updates.
For cyber devices, section 524B expects a reasonably justified regular cycle for known unacceptable vulnerabilities and out-of-cycle releases for critical ones. We set the cycle with your team in the maintenance plan and keep an emergency path ready.
Yes. We follow your procedures, use your change control and record in your eQMS. Where a procedure is missing for software, we draft one for your quality team to approve.
As long as the device is supported, or until your own team takes it back. The audit and maintenance plan come first, and we agree the scope of the first release on the scoping call.
Industries