OEM Instrument Software Explained: White-Label, Co-Branded and Licensed Models
Laboratory instruments are sold on their software as much as their optics or their fluidics. A gel imager that produces a picture is a camera; one that produces validated band quantities, an audit trail and a signed report is a product a QC lab can buy. Building that software is a different business from building hardware, which is why many instrument manufacturers get it from a partner under an OEM arrangement. This article explains how those arrangements work: the difference between white-label, co-branded and licensed-component models, how the software connects to the instrument, what a compliant edition for regulated customers involves, who owns what, and what to look for in a partner. It is written for product managers and engineering leads at instrument companies, and for the scientific software companies they talk to.
What OEM software means for an instrument company
In the instrument business, OEM software is software that ships with or for an instrument under the instrument maker’s brand but is developed, wholly or partly, by another company. The term is used loosely to cover several arrangements, from a complete control-and-analysis application carrying the instrument maker’s name to a single licensed component, such as a compliance module, embedded in the manufacturer’s own software.
What the arrangements have in common is that the instrument maker’s customer sees one product. The software carries the instrument’s brand, is supported through the instrument maker’s channels, and is sold as part of the instrument or as an option to it. The software partner’s name may appear (“powered by”) or may not.
Why instrument makers use a software partner
Analysis software is a discipline. Turning an image or a signal into a quantitative answer that a scientist will trust involves algorithms, statistics, validation on real data, an interface that fits laboratory work, and, for regulated customers, audit trails, electronic signatures and validation documentation. It also involves maintaining all of that through operating system changes for a decade or more.
An instrument company that builds this in-house has to hire and keep a scientific software team for a product line that may sell hundreds of units a year, and has to learn the regulatory side on its own first product. A partner who already builds and sells analysis software for the same techniques brings the algorithms, the validation experience and the compliance components on day one. TotalLab’s AuditSafe OEM page puts the alternative bluntly: building compliance features from scratch can take an engineering team 18 to 24 months. The partner route turns that into an integration which can take only a few weeks.
There is a commercial reason as well. Software differentiates the instrument. Two imagers with similar hardware sell on what their software lets the lab do, and a compliant edition opens the pharmaceutical QC market that an unregulated product cannot enter. Azure Biosystems’ AzureSpot Pro, built by TotalLab, followed exactly that path: an OEM image analysis platform, then a 21 CFR Part 11 and GMP-compliant edition that opened the regulated pharmaceutical market.
Three commercial models compared
The models differ in whose brand the customer sees, who owns what, and how the money flows.
White-label. The partner’s software, or software built on the partner’s platform, is delivered under the instrument maker’s brand alone. The customer sees the instrument maker’s product. The partner is typically paid a development fee for the branded edition and a per-unit or annual license for the platform underneath, and provides second-line support behind the instrument maker’s first line.
Co-branded. The software carries both names, for example the instrument maker’s product name with “powered by” the partner. The customer sees a partnership. This suits cases where the partner’s name adds credibility with the target market (a known analysis package inside a new instrument) and where both parties want the association. Commercial terms are similar to white-label, often with joint marketing.
Licensed component. The instrument maker keeps its own software and licenses a specific capability from the partner: an analysis engine, a file format library, or a compliance layer such as audit trails and electronic signatures. The partner’s component is embedded and may be invisible to the customer. This is the fastest route when the instrument maker’s software is sound and only lacks a piece; it is how AuditSafe is integrated by OEM partners.
| Property | White-label | Co-branded | Licensed component |
|---|---|---|---|
| What the customer sees | The instrument maker's product | Both brands, e.g. "powered by" | The instrument maker's product; the component may be invisible |
| What the partner supplies | A complete application built for or from its platform | The same, with shared branding | One capability: analysis engine, format library, compliance layer |
| Who owns the platform | Partner; instrument maker licenses it | Partner; instrument maker licenses it | Partner |
| Who owns the branded edition and extensions | Instrument maker, under contract | Shared, under contract | Instrument maker's own software stays its own |
| Typical commercial terms | Development fee plus per-unit or annual platform license | Development fee plus license, often with joint marketing | Per-unit, per-seat or annual license for the component |
| Support model | Instrument maker first line; partner second line | Shared, often visible to the customer | Instrument maker first line; partner supports the component |
| Time to market | Months: build the branded edition on an existing platform | Months | Weeks to a few months: integrate |
| Best when | The instrument needs complete analysis software and the maker has none | The partner's name sells | The maker's software is good but lacks a capability, most often compliance |
The models differ in whose brand the customer sees and who owns what. A licensed compliance component is the fastest route to a regulated-market edition.
How the software connects to the instrument
The integration between hardware and analysis software takes one of a few forms, and the choice affects cost, robustness and validation.
File-based. The instrument’s own acquisition software writes images or data files; the analysis software reads them. Simplest to build, loosely coupled, easy to validate, and adequate whenever acquisition and analysis are separate steps anyway. Most gel and blot imaging works this way. The essential requirement is a documented, stable file format, ideally with metadata (instrument, settings, calibration) embedded.
Driver or SDK. The analysis software controls acquisition directly through a software development kit or driver provided by the instrument maker or the camera vendor. Gives a single application from acquisition to report, which customers value, and lets the software enforce acquisition settings that matter for quantification (exposure, saturation, resolution). Costs more to build and ties the software to the hardware generation.
Service or API. The instrument runs an embedded service that the analysis software talks to over a network or USB protocol. Common in newer instruments and in anything designed for automation. Clean separation, testable, and the right basis for a product line rather than a single model; also the form that brings the EU Cyber Resilience Act’s obligations into full view, because the product is now a connected product with digital elements.
Embedded. The analysis runs on the instrument itself, on an embedded computer or a tablet. Appropriate for point-of-use instruments and automation; demands embedded engineering as well as analysis expertise.
| Integration | Coupling | Build effort | Validation | Best for |
|---|---|---|---|---|
| File-based | Loose | Low | Simple: file format is the interface | Imaging and analysis as separate steps; most gel, blot and plate work |
| Driver or SDK | Tight | Medium to high | Acquisition settings can be enforced and tested | Single acquire-to-report application; quantitative imaging |
| Service or API | Loose but live | Medium | Interface contract is testable; CRA obligations apply | Product lines, automation, connected instruments |
| Embedded | Tight | High | Whole device qualified together | Point-of-use instruments, automation platforms |
Whatever the integration, one requirement is constant for quantitative instruments: the software must know, and record, the acquisition conditions that affect the numbers. An image with no record of exposure and no saturation check cannot be quantified defensibly, and an inspector will ask. Our guide to imaging 2D gels explains why for one technique.
Compliance editions: opening the regulated market
Regulated laboratories, meaning pharmaceutical QC, biologics manufacturing, contract testing and anything else operating under GMP, cannot buy an instrument whose software lacks the controls of 21 CFR Part 11 and EU Annex 11: individual user accounts, a secure audit trail, electronic signatures, record protection, accurate copies and validation documentation. Bids are lost at the questionnaire stage. Our GMP compliant software article lists the nine controls a product needs.
GMP compliant software article
A compliance edition is the instrument’s software with those controls added, usually sold as a premium option. It is the OEM arrangement with the clearest return, because it opens a market that pays more and buys on validation rather than on price, and it is the one most often done as a licensed component. AuditSafe is TotalLab’s compliance layer: audit trails, electronic signatures, granular user permissions, Active Directory integration and image authenticity verification, integrated into an OEM partner’s software. World Precision Instruments used it to bring 21 CFR Part 11 compliance to their EVOM Auto product line for pharmaceutical and contract research customers.
The instrument maker’s obligations under a compliance edition are worth spelling out. The controls are the partner’s; the validation documentation for the integrated product is produced jointly; the customer’s own validation is the customer’s. The partner should supply a control-by-control mapping to Part 11 and Annex 11 and should be available to support customer audits, because the customer’s questions will come through the instrument maker.
Intellectual property, branding and support
The OEM contract has to answer four questions clearly, and a good partner will raise them first.
Who owns the platform. In white-label and co-branded models, the partner’s underlying platform (algorithms, engine, framework) stays the partner’s, and the instrument maker licenses it. The branded edition, its configuration, its extensions and its branding belong to the instrument maker. In the licensed-component model, the maker’s own software stays its own and the component is licensed. Ambiguity here is the commonest source of dispute; write it down.
What happens if the partner disappears. Source code escrow, released on defined triggers (insolvency, discontinuation, failure to support), is standard and reasonable. Ask for it.
Who supports the customer. First-line support is normally the instrument maker’s, because the customer bought an instrument; second-line, for the software itself, is the partner’s, with agreed response times. Training materials, release notes and known-issue lists should be supplied in a form the instrument maker can rebrand.
Who controls the roadmap. Operating system compatibility, security updates and defect fixes are the partner’s obligation for the term; feature development is scoped and priced. The contract should say how the instrument maker’s customers’ requests are prioritized and how long the platform will be supported.
| Term | What to specify |
|---|---|
| Platform ownership and license | What is licensed, for which products, in which territories, for how long, on what basis (per unit, per seat, annual) |
| Branded edition ownership | Instrument maker owns branding, configuration and its own extensions |
| Source code escrow | Agent, deposit frequency, release triggers |
| Support | First and second line, response and resolution times, hours, languages |
| Maintenance | Operating system compatibility, security updates, defect fixes, for the term |
| Roadmap and enhancements | How requests are scoped and priced; minimum platform support period |
| Compliance and validation | Control mapping supplied; joint validation documentation; audit support commitments |
| Cyber Resilience Act | Which party is the manufacturer for CRA purposes; SBOM, vulnerability handling and update delivery responsibilities |
| Data and confidentiality | Customer data stays with the instrument maker's customers; NDA; no use of data for the partner's other purposes |
| Exit | Transition support, continued license for units in the field, handover of documentation |
What an OEM engagement looks like
A typical OEM software engagement runs in five stages, and the first is short.
Discovery. The partner learns the instrument, the market, the existing software if any, and the customers’ analysis needs. For TotalLab this is a free 30-minute call followed by whatever technical review is needed.
Scope and proposal. Which model, which integration, which features in the first release, which compliance controls, the commercial terms above, and a timeline with a fixed view of what will be built.
Build. Iterative development against real instrument data from the first weeks, with the instrument maker’s product team reviewing working software rather than documents. For a branded edition on an existing platform this is measured in months; for a licensed component, weeks to a few months.
Validation and release. Verification against the specification, validation documentation for the integrated product, and, for a compliance edition, the control mapping and the IQ and OQ protocols the instrument maker’s customers will need. Our article on validating custom software describes the document set.
Support and enhancement. Second-line support, maintenance releases, and feature development as the product line grows.
Modernizing legacy instrument software
Many instrument makers do not need new software so much as they need their existing software to survive. Software written for an earlier operating system, with a dependency that is no longer maintained, no security update process and no audit trail, is a growing liability, and from 11 September 2026 the EU Cyber Resilience Act adds vulnerability reporting obligations for products with digital elements sold in the EU, with the main obligations applying from 11 December 2027.
The options are to patch, to wrap or to redevelop. Patching keeps an old codebase alive for a while and rarely delivers security or compliance. Wrapping adds a layer (for compliance, this is the licensed-component route) around software that is otherwise sound. Redeveloping the software while keeping the hardware, on a platform that already exists, is often faster than expected because the hardware interface is the only new work. Our survival guide to the Cyber Resilience Act for life science OEMs goes through the decision and the timeline.
How TotalLab works with OEMs
TotalLab has built and sold its own image and data analysis software for more than twenty years, covering 1D and 2D gels, Western blots, colony counting, arrays, ELISA, viral kinetics and LC-MS. That platform is what OEM editions are built on, and AuditSafe is the compliance layer that goes with it. For Azure Biosystems, TotalLab built AzureSpot Pro, an OEM image analysis platform, and then its 21 CFR Part 11 and GMP-compliant edition. For World Precision Instruments, AuditSafe brought 21 CFR Part 11 compliance to the EVOM Auto product line. The engagement runs from a free discovery call to a scoped proposal, an iterative build on real instrument data, validation documentation and second-line support.
Frequently asked questions
Q: What is OEM software for laboratory instruments?
A: Software that ships with or for an instrument under the instrument maker’s brand but is developed, wholly or partly, by a software partner. It ranges from a complete white-label control-and-analysis application to a single licensed component such as a compliance layer.
Q: What is the difference between white-label and co-branded software?
A: White-label software carries only the instrument maker’s brand; co-branded software carries both names, for example “powered by” the partner. The commercial structure is similar; the difference is what the customer sees and whether the partner’s reputation is part of the sale.
Q: How does OEM analysis software connect to an instrument?
A: Through files written by the acquisition software, through a driver or SDK that lets the software control acquisition, through a service or API on the instrument, or by running embedded on the instrument itself. File-based integration is simplest; driver and API integration give a single acquire-to-report product.
Q: What is a compliance edition of instrument software?
A: The instrument’s software with the controls required by 21 CFR Part 11 and EU Annex 11 added: individual user accounts, a secure audit trail, electronic signatures, record protection, accurate copies and validation documentation. It opens the regulated pharmaceutical and biologics market and is usually sold as a premium option.
Q: Who owns the software in an OEM partnership?
A: Typically the partner owns the underlying platform and licenses it; the instrument maker owns its branding, configuration and extensions, and its own software in a licensed-component model. Source code escrow protects the instrument maker if the partner disappears. The contract should state all of this explicitly.
Q: How long does it take to add 21 CFR Part 11 compliance to instrument software?
A: With a licensed compliance component such as AuditSafe, weeks to a few months of integration and validation, against the 18 to 24 months an engineering team can spend building the controls from scratch.
Q: Does the EU Cyber Resilience Act apply to laboratory instruments?
A: Instruments with software or connectivity sold in the EU are products with digital elements. Vulnerability reporting obligations apply from 11 September 2026 and the main obligations from 11 December 2027. The OEM contract should say which party carries which responsibilities.
Q: Which company builds OEM software for gel imagers and other lab instruments?
A: TotalLab builds white-label and co-branded analysis software on its own platform and licenses AuditSafe as a compliance component; Azure Biosystems and World Precision Instruments are named partners.
References
1. TotalLab. Azure Biosystems: OEM image analysis software (case study). https://totallab.com/case-studies/azure-biosystems-oem-image-analysis-software/
(Source for: AzureSpot Pro and its 21 CFR Part 11 and GMP-compliant edition.)
2. TotalLab. OEM 21 CFR Part 11 Compliance Integration, AuditSafe. https://totallab.com/auditsafe-oem/
(Source for: AuditSafe capabilities, the 18 to 24 month figure, and the World Precision Instruments EVOM Auto case.)
3. TotalLab. OEM Compliant Software Development. https://totallab.com/21cfr-software-development/
(Source for: the OEM engagement process.)
4. European Commission. Cyber Resilience Act. https://digital-strategy.ec.europa.eu/en/policies/cyber-resilience-act
(Source for: entry into force 10 December 2024; reporting obligations from 11 September 2026; main obligations from 11 December 2027; manufacturers’ vulnerability-handling duties.)
5. U.S. Food and Drug Administration. 21 CFR Part 11. eCFR. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11
(Source for: the controls a compliance edition must provide.)
6. European Commission. EudraLex Volume 4, Annex 11: Computerised Systems. https://health.ec.europa.eu/medicinal-products/eudralex/eudralex-volume-4_en
(Source for: supplier assessment and validation responsibilities in the regulated customer’s hands.)
Ship better software with your instrument
Whether your instrument needs complete analysis software under your brand, or your existing software needs a compliant edition to win regulated bids, TotalLab has done it for imaging and measurement instruments already on the market. Book a free 30-minute discovery call.
Book a free 30-minute discovery call