The Due Diligence Framework Defense Buyers Should Apply

Defense There is a conversation that happens in defense procurement offices around the world with uncomfortable regularity. A technology has been evaluated, demonstrated, and contracted. It has passed every certification test, satisfied every specification requirement, and impressed every technical evaluator who reviewed it. And then it is deployed, and it does not work the way it was supposed to work.

Not because the vendor was dishonest. Not because the evaluators were incompetent. But because the evaluation process asked the wrong questions, applied the wrong standards, and mistook laboratory certification for operational validation.

The gap between these two things, between a technology that has been certified and a technology that has been proven, is the central due diligence challenge in defense procurement. This guide is about how to close that gap systematically, before contract award rather than after deployment.

Why Certification Is Not Proof

Defense technology certification exists for good reasons. It provides a standardized framework for evaluating whether a system meets defined technical requirements. It creates a documented record of performance that procurement authorities can reference and defend. And it enables comparison between competing systems on a common baseline.

What certification cannot do is replicate the conditions of actual operational deployment. Certification standards are written in advance, based on known threat parameters, defined environmental conditions, and anticipated operational scenarios. The adversary who will attempt to defeat the system in the field has not read the certification standard and is not constrained by it.

This gap is not a flaw in certification systems; it is an inherent limitation of any assessment methodology that takes place before operational deployment. The question for procurement due diligence is not whether certification is valuable. It is whether certification alone is sufficient. For most categories of defense technology in the current threat environment, it is not.

The systems that have failed in operational deployment despite successful certification share a common profile: they performed correctly against the threat parameters defined by the certification standard, but failed against the threat parameters used by actual adversaries. Counter-UAS systems certified against drone signatures that were current eighteen months ago. Electronic warfare protection systems certified against jamming patterns documented before a conflict revealed new adversarial capabilities. Cyber defense platforms are certified against attack methodologies that a sophisticated threat actor has already moved beyond.

TRL-9, the standard that separates laboratory validation from operational proof, is specifically designed to address this gap. A system at TRL-9 has been deployed in actual operational conditions and demonstrated performance against actual threats. The certification documents what the system was designed to do. The TRL-9 designation documents what the system has actually done.

The due diligence framework that follows is built on the distinction between these two things.

The Five Questions That Separate Combat-Proven from Certified

Before examining any defense technology in depth, procurement authorities should establish answers to five foundational questions. The answers to these questions will determine whether a more detailed technical evaluation is warranted and, in some cases, will end the evaluation before it begins.

Question One: What is the specific operational environment in which this system has been deployed?

Not “has this system been deployed,”  which can be answered by any vendor with a single operational reference, but “in what specific operational environment.” The operational environment determines whether the deployment experience is relevant to your requirements.

A border surveillance system deployed on a flat, arid border has limited validation relevance for a procurement authority managing a forested, mountainous border. A cyber defense platform deployed against criminal threat actors has limited validation relevance against nation-state adversaries. A counter-UAS system deployed against commercially available drones has limited validation relevance against military-grade unmanned systems.

The operational environment in which Israeli defense technology has been validated, continuous multi-domain threat pressure, sophisticated adversarial actors, complex terrain, and electronic warfare environments, is relevant to a wider range of procurement requirements than most alternative validation environments. But the question must still be asked specifically, and the answer must be evaluated against your specific requirement, not against a generic standard.

Question Two: What is the documented performance record in that operational environment?

This is where the distinction between marketing material and due diligence evidence becomes most visible. Vendors will describe their operational deployments in terms that are accurate but selective, emphasizing successes, framing limitations as edge cases, and presenting operational experience as uniformly positive.

Due diligence requires documented performance data, not a narrative description. What was the system required to do? What did it actually do? How was performance measured? Who measured it? Is the measurement methodology independent of the vendor?

In the Israeli defense technology context, operational performance data is often classified or commercially sensitive. This is legitimate and expected. But there are two questions that can be answered even within classification constraints: has the system been used by the operational arm of the Israeli Defense Forces as a fielded capability, not a pilot, not a trial, not a proof of concept, but a deployed operational system? And is the vendor able to provide references from the operational authority that used it, through appropriate channels, that confirm operational performance?

A vendor who cannot answer yes to both of these questions is not offering TRL-9. They are offering something else with TRL-9 labeling.

Question Three: What failed, and what was changed as a result?

This is the question that most procurement evaluations never ask, and it is among the most revealing. Every operational system fails in some respect in deployment. Components underperform. Integration creates unexpected problems. Environmental conditions expose limitations that testing did not reveal. Edge cases occur that specification writers did not anticipate.

The response to operational failure is what distinguishes a mature, combat-proven system from a system that happened to perform adequately in its first deployment. A vendor who can describe specifically what failed in operational use, how the failure was diagnosed, what was changed as a result, and how the change was validated is describing a system that has been through the development cycle that operational experience drives. A vendor who describes only successes has either not deployed in a genuinely demanding environment or is not being forthcoming about the development history.

In the Israeli defense technology ecosystem, the development cycle driven by operational experience is a structural feature of how technology matures. Systems are deployed, failures are identified, modifications are made, and the modified system is redeployed, in many cases multiple times across multiple operational contexts. The resulting capability reflects accumulated operational learning in a way that laboratory development cycles cannot replicate.

Question Four: What are the conditions under which this system will not perform as specified?

Every system has operational limits. The due diligence question is whether those limits are known, documented, and compatible with your operational requirements, or whether they are unknown because the system has not been tested against the conditions that would reveal them.

A vendor who can clearly articulate the operational envelope of their system, the environmental conditions, the adversarial parameters, the operational tempos, and the integration requirements within which the system performs as specified, and outside which performance degrades, is describing a system whose limits are understood. Understanding limits is a function of operational experience. Systems that have been deployed know where they fail, because they have failed there and the failure has been observed.

A vendor who cannot clearly articulate operational limits is describing either a system that has not been deployed in genuinely demanding conditions or a vendor who is not engaging with the due diligence question honestly. Neither is acceptable for a procurement decision.

Question Five: Who else is operating this system, and can we speak with them?

References from operational users are the single most valuable piece of evidence available to a procurement authority, and they are among the least frequently obtained in formal procurement processes. Tender procedures often do not create space for reference conversations. Vendor-provided references are, by definition, selective. And operational users of classified or sensitive defense systems are not always in a position to discuss their experience openly.

None of this makes reference conversations impossible. It makes them require effort, which is precisely why most procurement processes do not obtain them and why the procurement authorities that do obtain them consistently make better acquisition decisions.

In the Israeli defense context, reference conversations are possible through appropriate channels. DECA-licensed suppliers operate within a regulatory framework that creates traceable engagement records. The operational authorities that have used Israeli defense systems  IDF units, Israeli intelligence services, allied forces who have operated Israeli-supplied equipment  are accessible through defense attaché networks, established bilateral military relationships, and the institutional connections that experienced defense export intermediaries maintain.

A procurement authority that accepts vendor assertions about operational performance without seeking independent confirmation from operational users is not conducting due diligence. It is conducting a sophisticated vendor briefing.

The TRL-9 Verification Protocol

Beyond the five foundational questions, procurement authorities evaluating Israeli defense technology should apply a specific verification protocol to claims of TRL-9 validation. The protocol consists of four elements.

Element One: Identify the specific deployment.

TRL-9 requires demonstration in actual mission operations. Ask the vendor to identify specifically by system designation, by operational context, and by timeframe where and when the system has been used in actual mission operations. Not “our technology has been used by the IDF”  but “this specific system, designated [X], was deployed in [operational context] during [timeframe] and performed [specific functions].”

Vague answers to this question are informative. A vendor who cannot be specific about the operational deployment behind a TRL-9 claim either does not have a TRL-9 system or is not engaging with the question honestly.

Element Two: Distinguish system from component.

A system that integrates TRL-9 components is not itself necessarily at TRL-9. A new integration architecture, even of proven components, introduces integration risk that the individual component validations do not address. Ask specifically whether the system, as configured for your procurement, including all integration elements, all interface requirements, and all operational support components  has been validated at TRL-9, or whether individual components have been validated at TRL-9 and the integration is new.

This distinction matters because most procurement failures in technology-intensive defense systems occur at integration, not at the component level. Components that perform correctly in isolation can create systems that fail when connected. TRL-9 at the system level, not the component level is what the procurement authority needs.

Element Three: Assess the relevance of the validation environment.

As discussed above, operational validation in one environment does not automatically transfer to another. Once the specific deployment has been identified, assess whether the operational conditions of that deployment are sufficiently similar to your operational requirement to make the validation relevant.

This is a judgment call that requires operational expertise on the procurement side. If the procurement authority does not have the internal expertise to make this assessment, which is common, particularly for procurement authorities in countries with less mature defense establishments, it should obtain an independent technical assessment from a party with no commercial interest in the outcome.

Element Four: Verify through channels independent of the vendor.

The vendor’s account of their own system’s operational performance is necessary but not sufficient. Every element of the TRL-9 claim that can be verified through independent channels should be. Israeli Ministry of Defense records, defense attaché networks, allied force operational experience, and reference conversations with operational users are all potential independent verification sources.

The regulatory framework of DECA licensing is itself a partial verification mechanism. A DECA-licensed export authorization confirms that the Israeli government has assessed the technology and authorized its export. It does not confirm operational performance, but it confirms that the exporting entity and the technology have passed the Israeli Ministry of Defense’s regulatory assessment, which is an independent validation of a different kind.

The Checklist: Questions to Ask an Israeli Defense Technology Vendor

The following questions translate the framework above into a practical evaluation checklist. They are organized in the sequence in which they should be asked, beginning with foundational regulatory and authorization questions before moving to technical and operational evaluation.

Regulatory and Authorization:
Has this technology received specific DECA export authorization for the intended end-use and end-user? Can you provide documentation of the current DECA licensing? Is the proposed transaction structured to comply with all applicable Israeli export control requirements, including end-user commitments and retransfer restrictions?

Operational Validation:
In what specific operational context has this system been deployed as a fielded capability by the Israeli Defense Forces or an allied operational authority? What is the specific system designation and the timeframe of deployment? Can you provide an operational reference who can confirm this deployment through appropriate channels?

Performance Documentation:
What documented performance data exists from operational deployment? What were the performance metrics defined for the operational deployment, and what results were achieved against those metrics? Is performance data available through official channels, the defense attaché network, bilateral military agreement, or official reference from the operational authority?

Failure and Development History:
What operational failures or performance limitations have been identified through deployment? What modifications were made as a result? How were those modifications validated? What are the current known operational limits of the system?

Integration and Configuration:
Is the system as configured for this procurement, including all integration elements and interface requirements at TRL-9, or are individual components at TRL-9 with the integration representing new development? What integration risk does the proposed configuration carry, and how has that risk been assessed?

Support and Life-Cycle:
What in-country support infrastructure exists for this system? What is the maintenance and upgrade roadmap? How will supply chain continuity be maintained over the operational life of the system? What are the retransfer and co-production constraints under the DECA export authorization?

What Good Due Diligence Produces

A procurement authority that applies this framework rigorously will reach one of three conclusions about any given Israeli defense technology.

The first conclusion is that the system is genuinely at TRL-9, the validation environment is relevant to the procurement requirement, the regulatory authorization is in place, and the operational limits are compatible with the intended use. This is the conclusion that justifies proceeding to the contract.

The second conclusion is that the system has genuine operational experience, but not at the specific TRL-9 level claimed, or in an operational environment that is not sufficiently relevant to the procurement requirement. This does not necessarily disqualify the technology; it requires an honest conversation with the vendor about what additional validation would be required and what risk the procurement authority is accepting by proceeding.

The third conclusion is that the TRL-9 claim is not substantiated by the evidence available through the due diligence process. This is a disqualifying finding. A vendor who cannot support a TRL-9 claim through the questions above is either offering a system that is not at TRL-9 or is not engaging with the procurement process in the good faith that responsible defense acquisition requires.

The purpose of due diligence is not to disqualify vendors. It is to ensure that the technology a government acquires to protect its national security has actually been proven to do what it claims to do in conditions that resemble the conditions under which it will actually be used. In a market where the gap between marketing claims and operational reality is wide, and where the consequences of that gap are measured in national security exposure rather than commercial inconvenience, this due diligence is not optional.

It is the minimum standard that responsible procurement demands.

A Note on Tel Aviv Capital’s Approach

Tel Aviv Capital applies the framework above before representing any technology, not after procurement authorities ask for it. Every solution in our portfolio has been evaluated against the five foundational questions and the TRL-9 verification protocol before we introduce it to a procurement authority. We decline to represent technologies that cannot satisfy this framework, regardless of their commercial potential.

This is not a marketing position. It is an operational commitment that reflects our understanding of what our procurement authority partners need and what they are entitled to receive from a regulated, DECA-licensed defense firm that operates under Israeli Ministry of Defense oversight.

The questions above are available to any procurement authority evaluating any Israeli defense technology, through Tel Aviv Capital or through any other channel. We encourage their use. The market for defense technology works better when procurement authorities ask hard questions, and the technologies that cannot answer them are identified before they are deployed.

Defense procurement authorities seeking a regulated partner who applies this framework before, not after technology introduction, are invited to contact Tel Aviv Capital. All engagements are conducted under NDA and full DECA compliance.