Due Diligence

Until you do due diligence, no one knows...

Technical due diligence for kernel software is an independent assessment of a kernel-mode codebase conducted in the context of a merger, acquisition, partnership, or licensing decision. The goal is to give the acquiring or investing party an accurate picture of the code quality, security posture, compatibility, and maintainability of the software before the deal closes. For kernel-mode drivers and system software specifically, hidden defects carry costs that are easy to underestimate from the outside: a driver that crashes on current Windows versions requires a remediation effort before the product can ship, a driver with known security vulnerabilities creates immediate liability, and a driver that depends on undocumented kernel interfaces may break with any future Windows update.

Our impartial evaluation gives you the information you need while insulating you from intellectual property risks if the deal ultimately doesn't happen. We have significant experience on a wide range of platforms including Windows and Linux, classes of business and software ranging from small startups to fortune 500 companies. We understand the sensitivities of your intellectual property and your code.

Technical due diligence often pairs well with our driver code review service for a deeper codebase analysis, or with reverse engineering when compiled binaries must be evaluated without source code. Contact us to discuss your evaluation requirements.

What We Assess

A Joya Systems technical due diligence assessment of a Windows driver codebase examines:

  • Code quality and architecture.The soundness of the driver's design decisions (device stack position, I/O model, locking strategy) and the quality of the implementation, including adherence to documented Windows Driver Kit patterns and avoidance of common kernel-mode pitfalls.
  • Security posture. Known vulnerability classes in kernel-mode code: improper user-mode input validation, integer overflows in size calculations, use-after-free patterns, and privilege escalation paths through exposed IOCTL interfaces.
  • Windows version compatibility. Whether the driver works correctly on current Windows 10 and Windows 11 releases, meets Driver Signature Enforcement and HVCI (Hypervisor-Protected Code Integrity) requirements, and is free of dependencies on undocumented or deprecated kernel interfaces.
  • Driver signing and WHQL status. The current signing status, whether it holds a valid Microsoft hardware signature, and whether it is compatible with Secure Boot-enabled systems.
  • Maintainability. The quality of test coverage, build reproducibility, and the extent to which the codebase can be safely modified by engineers who did not write the original code.

Engagement Scenarios

The most common scenario is M&A: an acquiring company discovers that the acquisition target's product includes a Windows driver component, and the technical due diligence process needs to include an assessment of that component by engineers who understand kernel-mode software. OEM licensing evaluation is another frequent request, where a hardware vendor is about to take a dependency on a software company's driver and wants an independent technical opinion before committing. Contractor-delivery acceptance is a third: a company outsourced driver development to a third party and wants an independent review before accepting delivery and making the final payment. In each case the output is a written independent assessment, though the framing and depth of analysis may differ based on what information is available and how much time the transaction allows.

What You Receive

At the conclusion of a due diligence engagement you receive a written assessment report that documents findings by category and severity, explains the technical basis for each finding, and provides an overall risk rating for the codebase. The report is written to be understood by non-technical stakeholders such as legal and investment teams, with a technical appendix that gives the engineering team the specific detail they need to evaluate and prioritize remediation. If source code is not available, we can perform a binary-level analysis using reverse engineering techniques; see our reverse engineering services for details. For a more comprehensive source-level review, our driver code review and due diligence assessments can be combined into a single engagement. Contact us to discuss the timeline and scope of your transaction.

Frequently Asked Questions

What is technical due diligence for driver software?
Technical due diligence for driver software is an independent assessment of a kernel-mode codebase conducted in the context of a merger, acquisition, or investment decision. The goal is to give the acquiring party an accurate picture of the code quality, security posture, maintainability, and technical risk before the deal closes. For kernel-mode software in particular, hidden defects — race conditions, memory corruption, incompatibility with newer Windows versions — can be far more expensive to remediate post-acquisition than they appear from the outside.
What does a kernel software acquisition assessment include?
A thorough assessment covers code quality and architecture review, identification of known vulnerability patterns specific to kernel-mode development, compatibility with current and upcoming Windows versions, the state of driver signing and Windows Hardware Lab Kit (HLK) certification, an evaluation of test coverage and build practices, and an assessment of dependence on undocumented or deprecated kernel interfaces. The output is a written report with findings categorized by severity and a prioritized remediation plan.
How do you evaluate the quality of a Windows driver codebase?
We evaluate driver codebases by reading the source directly and applying the same criteria used in our code review service: IRQL discipline, correct IRP completion paths, memory management, locking correctness, and handling of edge cases such as driver unload and surprise removal. We also examine historical crash data if available, Driver Verifier test results, and how the code is structured for ongoing maintenance. Code that compiles cleanly but fails basic Driver Verifier tests or crashes on a current Windows version represents a material risk regardless of how the product performs in demonstrations.

Our Services

  • What our customers say about us?