On-Premise & Air-Gapped Pentest Platforms: A Buyer's Guide

Most buyers compare pentest platforms on what they find. For regulated organizations the first filter is often somewhere else: where the platform's control plane and AI run, and therefore where the findings, credentials and evidence go.

That choice decides three things a risk committee cares about:

• Who is a third party. A vendor cloud that receives your findings is a service provider that processes your security data, with its own locations, subcontractors and staff.
• What has to be assessed and contracted. Every such provider adds due diligence, contract clauses, monitoring and an exit plan.
• What happens if the vendor stops. If testing depends on a vendor cloud, a suspension, outage or insolvency stops your testing too.

None of the rules below bans a cloud-hosted pentest platform, and many organizations run one after doing that work. The point of this guide is to make the work visible before the purchase, and to show what an on-premise or air-gapped option actually has to deliver to remove it.

• Defense, armed forces and the defense industrial base. Classified and controlled information, networks that are air-gapped by rule, and for US defense suppliers the CMMC scoping rules on where CUI and security data may go. See defense and air-gapped networks and US defense industrial base (CMMC).
• Public administration and government. National-security and data-classification rules, such as Italy's national cybersecurity perimeter, and the principle that the tools defending the state stay under its control.
• Banks, insurers and market infrastructure. ICT third-party risk, concentration risk and exit strategies under DORA in the EU, and outsourcing or data-residency rules from national supervisors elsewhere.
• Healthcare and life sciences. Special categories of personal data under GDPR Art. 9, HIPAA business-associate obligations in the US, and hospitals classed as essential entities under NIS2.
• Operators of OT and industrial networks. Plant, energy and utility networks that are deliberately isolated, where a tool that needs a standing internet connection cannot be installed at all.

The common thread is not size but the sensitivity of the security data and the isolation of the network. The full list, with the regulatory driver for each sector, is on the on-premise AI red team page.

DORA (EU financial entities). Article 3(21) defines ICT services as digital and data services provided through ICT systems on an ongoing basis, including hardware services with technical support via software or firmware updates by the hardware provider. A cloud platform is an ICT service; so is an on-premise appliance whose vendor ships updates. Either way the vendor goes into the register of information of Article 28(3), and Article 28(4) requires a pre-contract assessment that includes concentration risk. The deployment model changes what that assessment has to cover:

• Article 30(2)(b) requires the contract to state the regions or countries where the service is provided and where data is processed, including the storage location, with advance notice of any change. With a vendor cloud, that is the vendor's hosting; on-premise, it is your own site.
• Article 29(2) asks entities to weigh subcontracting chains and providers established in third countries, including data protection and law enforcement there. A SaaS platform that calls a third-party AI model adds a link to that chain.
• For services supporting critical or important functions, Article 28(8) requires tested exit strategies, and Article 30(3)(f) a transition period. If the testing capability lives in the vendor's cloud, exit means losing it; if it runs on hardware you hold, exit is a question of licensing and support.

NIS2 (essential and important entities). Article 21(2)(d) lists supply chain security, including security-related aspects of the relationships between each entity and its direct suppliers or service providers, among the mandatory risk-management measures, and Article 21(3) requires entities to take into account the vulnerabilities specific to each supplier and the quality of its products and cybersecurity practices. A testing platform holds privileged knowledge of your weaknesses; where it sends that knowledge is part of the supplier assessment.

CMMC (US defense contractors). 32 CFR 170.4 defines an External Service Provider as external people, technology or facilities used for IT or cybersecurity services, and states that CUI or Security Protection Data must be processed, stored or transmitted on the provider's assets for it to count as one. Security Protection Data expressly includes data related to the configuration or vulnerability status of in-scope assets and passwords that grant access to the in-scope environment. A cloud pentest service that receives findings or test credentials is therefore an ESP in your assessment scope. The CMMC Phase 2 evidence playbook covers the scoping consequences.

Vendors use on-premise for very different architectures: a local sensor driven from a cloud console, a local engine calling a cloud AI model, or a self-contained appliance. Define the term in the contract, item by item:

• No telemetry by default. List every outbound connection the product makes in normal operation, its destination and its payload. Anything beyond that list should be opt-in and documented.
• Local AI models. State where inference runs. If any prompt, finding or credential can reach an external model endpoint, that provider is a third party and belongs in your assessment. See private AI in cybersecurity.
• Offline licensing. The platform should keep running if it cannot reach the vendor, with the license term checked locally, so a vendor outage, dispute or insolvency does not switch off your testing.
• A controlled update process. Updates signed by the vendor, verifiable before installation, applicable offline where the network is isolated, and installed when you decide.
• Local evidence storage. Findings, evidence and credentials stored on your hardware, with integrity you can verify without the vendor and export formats you can keep after the contract ends.
• Data deletion. How data is wiped when the contract ends or hardware goes back for repair or replacement, and what proof of destruction is provided.
• Remote support. Whether the vendor ever needs remote access, who approves it, and how it is logged.
• Air-gapped behavior. Which features depend on the internet and are lost when the platform is fully isolated, so the test scope is planned around them.

Deployment options differ more than category labels suggest. From the documentation we reviewed for our comparison pages:

• Horizon3.ai NodeZero runs from a customer-hosted host but is orchestrated from Horizon3's cloud, which that host needs continuous outbound access to during a test; an EU-hosted portal is available, and no air-gapped edition is documented.
• Pentera Core installs on your own infrastructure, while Pentera Surface is hosted on AWS and its generative-AI features call a cloud LLM service; no fully air-gapped operation is documented.
• Cymulate is SaaS-only: lightweight test points run on your network, while the platform and its AI run in Cymulate's cloud.
• XM Cyber is SaaS by default with EU hosting options and BSI C5; we found no documented fully on-premise or air-gapped edition.
• XBOW is delivered as SaaS on third-party frontier models and targets internet-facing web apps and APIs.
• Picus Security, a breach and attack simulation (BAS) vendor, is SaaS-first but does document on-premise and air-gapped deployment.

Two fair conclusions follow. SaaS platforms bring real advantages, faster onboarding and no hardware to manage, and for organizations without the constraints above they may be the right choice. And on-premise or air-gapped options are not unique to one vendor: ask every shortlisted vendor the questions below and read the answers in the contract, not the datasheet. Vendor documentation changes; verify each point with the vendor at the time of purchase. Side-by-side pages are on alternatives.

1. List every outbound connection the platform makes in normal operation, with destination and payload. Can each one be switched off?
2. Where do the AI models run? Can any prompt, finding or credential reach an external inference endpoint, and who owns the models?
3. Does the platform run fully with no internet connection? Which features are lost in air-gapped mode?
4. Is there any telemetry, including usage, crash or update-status reporting? Is it off by default, and what does the payload contain?
5. How is the license enforced? Does the platform keep working if it cannot reach the vendor, and what happens at the end of the term?
6. How are updates delivered, signed and verified, and can they be applied offline at a time you choose?
7. What do updates contain, and do you see release notes before installing?
8. Where are findings, evidence and test credentials stored, and can you verify their integrity without the vendor?
9. In which formats can evidence and reports be exported so they remain usable after the contract ends?
10. How is data deleted at contract end or when hardware is returned, and what proof of destruction is provided?
11. Does support ever require remote access? Who approves it, and how is it limited and logged?
12. Which subcontractors, hosting providers or AI providers touch your data, and in which countries (DORA Art. 29(2) and 30(2)(b))?
13. Is a software bill of materials available for the platform, and how are vulnerabilities in the platform itself handled and disclosed?
14. What independent assurance covers the vendor and the product: certifications and their status, and third-party penetration tests of the platform?
15. How does the platform stay inside the authorized scope, who approves risky actions, and how is it stopped? The OWASP APTS guide for buyers turns this question into a structured evaluation.

Keep the answers with the contract. Under DORA they feed the register of information and the exit plan; under NIS2 the supplier assessment; under CMMC the asset inventory and the system security plan.

Zero Hunt is an autonomous AI red team for networks and infrastructure delivered as an appliance, a desktop unit for smaller sites or a 2U rack for enterprises and data centers. What the site states about its deployment, mapped to the checklist:

• Outbound connections and telemetry: the full stack, including the AI models, the evidence store and the console, runs on the appliance, and no customer data leaves it. When connected, the appliance reaches out only to fetch signed product updates, public threat intelligence and, for gray-box analysis, the published source of the software version under test, which can be switched off or pointed at your own source mirror. Update-status reporting (release ID, status, timestamp) is opt-in.
• AI models: its own ZeroHunt Apex models run on the appliance GPU, with no external AI API.
• Air-gapped mode: nothing goes out; updates arrive as signed offline bundles and threat intelligence as offline imports. Public-OSINT reconnaissance and downloading published source are switched off there, so those assessments run black-box, unless the appliance can reach your own source mirrors.
• Licensing: with an offline license the appliance checks its term locally and does not need to reach Zero Hunt to keep running.
• Evidence: each attack attempt is recorded in a signed, hash-chained evidence record kept on the appliance, and exported reports are signed.
• Assurance: the Trust Center states the current status openly: the appliance image is pentested annually by an independent firm, ISO/IEC 27001 is in progress and SOC 2 Type II is planned. See the Trust Center.

Two honest caveats. On-premise does not take Zero Hunt out of a DORA register: a vendor that ships updates provides an ICT service under Article 3(21), so it still needs to be recorded and assessed, but the data location is your own site. And items such as data deletion at contract end or hardware return are matters for the contract; ask for them in writing, as you would from any vendor. To check the fit with your environment, request a demo.

• Regulation (EU) 2022/2554 (DORA), Articles 3(21), 28, 29 and 30 (EUR-Lex)
• Directive (EU) 2022/2555 (NIS2), Article 21(2)(d) and 21(3) (EUR-Lex)
• 32 CFR 170.4, definitions of External Service Provider and Security Protection Data (eCFR)
• Vendor deployment facts: Zero Hunt comparison pages for Horizon3.ai, Pentera, Cymulate, XM Cyber, XBOW and Picus Security. Verify current deployment options with each vendor.