The Demise of Oxygen Forensic Detective?
The deeper story is about what laboratories buy when they buy forensic software: trust in a supplier, years of accumulated expertise and the ability to return to their evidence.
A forensic tool can remain technically useful while becoming difficult for an institution to trust. That is the more consequential question raised by the Oxygen Forensics crisis: how much of a laboratory’s ability to explain and revisit its work rests on a company it does not control?
The familiar response to a vendor crisis is to ask which product should replace it. Our argument starts one step earlier. Procurement needs to examine the origin and control of the software; budgets need to account for the accumulated dependency; and any recovery in confidence needs verifiable commitments. A different logo on the next purchase order does not answer those questions.
IN THIS ARTICLE
A serious crisis, with important limits
The product at the centre of the story
Oxygen Forensic Detective is the subject of this analysis. The Oxygen Forensics logo is reproduced for editorial identification.
On 23 September 2026, the US Department of Justice announced the arrests of Oxygen Forensics CEO Lee Reiber and Oleg Sergeyevich Davydov on a complaint charging conspiracy to commit wire fraud. Prosecutors allege that Russian ownership, control and software development were concealed from US government customers. Approximately 57 domains and related infrastructure were seized on 20 September.
The defendants are presumed innocent. The Justice Department expressly says the complaint does not allege malicious code or unauthorised access to customer systems or data. These allegations therefore do not establish that Oxygen was spyware or that its forensic results were manipulated.
Source: US Department of Justice announcement, 23 September 2026.
The analysis that follows concerns how a laboratory should evaluate a critical supplier under uncertainty. It does not depend on predicting a verdict, asserting a shutdown or claiming to know what every Oxygen customer is experiencing.
The procurement blind spot: who examines the examiner’s tools?
Laboratories scrutinise where evidence came from, who handled it and how it was processed. The uncomfortable procurement question is whether they apply comparable discipline to the software that turns that evidence into an intelligible account.
This is not an assertion that all laboratories neglect supplier checks. It is a test of what those checks actually establish. A successful demonstration answers a capability question. A headquarters address answers a location question. Neither, by itself, identifies who can direct development, approve a release or change the systems through which updates reach customers.
Corporate origin and software control are different questions
Place of incorporation, beneficial ownership, developer location and control of the release process should be examined separately. Treating one as a substitute for the others produces an assurance gap. Equally, nationality alone is not evidence that software is malicious. The useful question is whether the supplier’s account is accurate, complete and independently supportable.
Forensic procurement should follow authority as well as geography: who can approve a change, who can publish it, who can investigate an incident, and who is accountable when the published explanation proves incomplete? A signed installer can help establish its origin and integrity; a signature cannot, on its own, establish that every behaviour of the program is trustworthy.
NIST’s Secure Software Development Framework gives purchasers and suppliers a vocabulary for discussing development practices. That is a useful starting point for asking for evidence about a supplier’s process. It is not a certification of Oxygen or a substitute for testing the particular forensic functions a laboratory uses.
The missing link in a procurement file
A laboratory should be able to explain both why it trusts a result and why it trusts the organisation maintaining the tool. Evidence supporting one answer cannot automatically supply the other.
The practical improvement is to make supplier assurance an ongoing responsibility. Ownership and access arrangements can change between renewals. A procurement file needs an accountable owner, a review interval and agreed notification triggers. Collecting a declaration once and filing it indefinitely is a weak foundation for a long relationship.
Three things a forensic platform must let you defend
The evidence
Trace the finding back to its source and explain the interpretation.
The supplier
Verify who controls development, releases and privileged access.
The future
Retain a workable route to historical cases if service ends.
The cost of dependency: the licence is only the visible investment
Software budgets make licence fees easy to see. They are less effective at showing what accumulates around a platform: examiner training, validated procedures, report conventions, automation and familiarity with the way a tool represents records.
Those investments are not mistakes. Familiarity can make an examiner more effective and a procedure more repeatable. The risk arises when their value cannot survive a supplier interruption—or when nobody has tested whether it can.
A case may outlive the commercial relationship
Consider an illustrative scenario, not a reported Wildfire or Oxygen incident. A laboratory needs to revisit a case completed several years earlier. It has the report and a proprietary case database, but the original workstation has failed. Its challenge is no longer simply to buy another licence. It must establish which version produced the findings, whether it can lawfully restore a compatible environment, and how the reported items relate to the preserved acquisition.
A PDF may preserve what an examiner said. It does not necessarily preserve the ability to examine how the software reached the displayed result. An export may retain messages but omit relationships or processing context needed to understand them. The question is not whether a file can be exported; it is whether the exported material is sufficient for the work that might later be required.
That distinction changes how the cost of a platform should be assessed. The financial exposure includes the work needed to preserve, explain or reconstruct the method—not just the price of its replacement.
Four costs to make visible before renewal
- People
- Training time and the expertise needed to interpret unfamiliar output.
- Procedures
- Revalidation of workflows, reporting and quality controls after a change.
- Historical work
- Preserving access, version information, source records and the links between them.
- Interruption
- Delay and duplicated effort while important functions or support are unavailable.
Test the exit while the relationship is healthy
One practical procurement test is a controlled exit rehearsal using a representative training case. Can another competent examiner understand the material outside the primary platform? Can the team locate source records behind significant findings? Which relationships, annotations or logs fail to travel with the export?
Record the gaps and the effort required. Preserve permitted installation material, configuration records and version details in accordance with licensing and security requirements. Establish what remains accessible if an entitlement expires or an online service disappears. Do not assume an offline capability or perpetual access simply because the application works today.
Switching vendors may still be the right decision. But a rushed switch can exchange one unmeasured dependency for another. A more useful purchasing objective is to retain control over the evidence and enough context to explain it throughout its required life.
What would restore confidence: evidence that can be checked
A vendor facing a confidence crisis cannot resolve every buyer’s concern with a press statement. A statement can clarify a position; sustained confidence requires arrangements that customers can verify and rely on.
Nor should procurement assurance be confused with the outcome of criminal proceedings. A verdict addresses the matters before the court. A laboratory’s future purchasing decision also needs answers about present control, maintenance and continuity. Those are different assessments, and neither should be used to prejudge the other.
A practical standard for reassurance
The following is our proposed evaluation framework, not a claim that Oxygen has supplied these materials or that it has failed every test.
| Question | Evidence worth examining | What it would establish |
|---|---|---|
| Who actually controls the business? | Ownership and control disclosures corroborated against appropriate records, with a process for notifying changes. | An accountable, checkable account of control beyond a trading name or office address. |
| Who controls the software? | A documented release process, defined privileged roles and independent assessment with an explicit scope, date and limitations. | Which development and release controls have been examined, and what remains outside that examination. |
| Can customers continue their work? | Clear support and licence terms, tested restoration and export procedures, and named responsibility for interruptions. | A practical route to continuing or revisiting work, with remaining dependencies identified. |
| Can important results be reproduced? | Version-specific testing on known data, documented discrepancies and traceability to underlying records. | Evidence about defined functions under stated conditions—not a blanket assurance about every result. |
Independent oversight also needs scrutiny. Who commissioned the assessment? What was examined? Could the reviewer inspect the systems that matter? What limitations were reported, and what changed afterwards? “Audited” is not a useful conclusion without that context.
Continuity promises deserve the same treatment. Source-code escrow, for example, may sound reassuring, but source code alone would not establish that a customer has the rights, build environment, expertise and dependencies required to maintain a complex product. Any such arrangement should be assessed for what it would enable in practice.
Confidence should therefore return in stages, tied to specific evidence. A buyer might gain confidence in historical case access before becoming comfortable with new releases, or accept a defined function while seeking more information about another. That is more defensible than treating trust as a single switch that is either completely on or completely off.
Existing cases need a focused review, not an assumption
Concern about a supplier should prompt careful questions about completed work. It does not answer those questions. The relevant starting point is the particular finding: what source supports it, which software version processed it, and how much interpretation occurred between the source and the report?
NIST’s digital forensics programme and forensic reference datasets support testing against documented material. The lesson for this situation is methodological: define the function being examined and compare its output with something whose content is known. A supplier’s reputation cannot substitute for that work.
A proportionate review would preserve original acquisitions, logs, versions and reports; identify important conclusions that depend on automated interpretation; and independently examine those conclusions where feasible. Comparing a second tool’s output can help, but agreement alone is not a complete explanation of what a record means.
Any discrepancy should be documented with its effect on the conclusion. That approach allows concern to be translated into a specific, answerable technical question. It also avoids turning uncertainty about a company into an unsupported claim about every case processed with its software.
The standard worth defending
The most useful lesson from the Oxygen episode is not that laboratories should distrust every specialist vendor. It is that a forensic platform should be purchased with a clear view of what must remain under the laboratory’s control.
That includes the ability to explain significant results, scrutinise the supplier’s representations and return to important work if the commercial relationship fails. A procurement process that rewards features while leaving those questions unresolved understates what is really being bought.
Buy the ability to defend and continue the method
A familiar interface is valuable. The ability to preserve the evidence, explain the interpretation and continue the work is more enduring.
Whether Oxygen Forensic Detective recovers, restructures or ultimately disappears remains unresolved. The three tests above retain their value whichever outcome follows. They give laboratories a way to make a stronger decision now, without inventing certainty about the future.
Sources and editorial approach
The prosecution account is attributed to the official announcement. The procurement, dependency and confidence frameworks are our analysis. The illustrative historical-case scenario is hypothetical. No firsthand Wildfire use of Oxygen, source-code audit or customer compromise is claimed.
- US Department of Justice: announcement of arrests and allegations — 23 September 2026; includes the limits of the complaint and presumption of innocence.
- NIST SP 800-218: Secure Software Development Framework, version 1.1 — a reference for discussing development practices with suppliers.
- NIST: Digital Forensics — tool testing and forensic research context.
- NIST: Computer Forensic Reference Data Sets — documented datasets for evaluating forensic tools.
