How do you pen test a device that isn’t on the network?
Your cloud build is easy to test. A tester logs in and gets to work. The version you package as a VM for a hospital’s air-gapped network is a different problem entirely, there’s no route in for anyone, which is rather the point. This one’s for SaMD teams shipping more than one deployment model, wondering how a tester is meant to attack something specifically built not to be reachable.
Key Takeaways
- It's not usually an access problem, it's a "what are we actually testing" problem. Most of what needs testing in an air-gapped appliance doesn't need physical isolation to test properly.
- Separate the appliance from the isolation. The software inside the VM can be tested in an ordinary lab. The isolation itself, the boundary controls, is a smaller, different piece of work.
- FDA's 2026 guidance expects a production-equivalent configuration, not a description of one. If you ship two deployment models, both need representative evidence.
- Keep architecture consistent across deployments and you're testing a delta each time, not rebuilding the whole programme.
- Where a live representative network genuinely can't be replicated, say so. Scope a focused architecture review of the boundary alongside a full test of the appliance.
Why this matters now
The FDA's premarket cybersecurity guidance, reissued 3 February 2026, doesn't treat penetration testing as a single checkbox. It's one of ten listed testing and analysis activities under Section 524B, alongside fuzz testing, attack surface analysis, and static and dynamic code analysis, and it expects that testing to run against a production-equivalent configuration: the exact build that will ship, not an early prototype. Testers are expected to be independent of the design team, findings get mapped back to the threat model, and material design changes trigger a retest. None of that changes because a deployment model happens to be offline.
What are we actually testing?
Split the problem into two pieces and it stops being a blocker. One piece is the application itself, the containers, the OS, the API, the database, packaged into the VM or OVA appliance. None of that needs a real air gap to test properly; it's the same software whether it's running in a hospital's hypervisor or a tester's own virtualisation stack. The other piece is the isolation itself, the firewall rules, the one-way data flows, the assumption that the appliance never needs an outbound connection. That's a smaller, more specific piece of work, and it's the only part that genuinely benefits from something closer to the real network topology.
| Component | True replication needed? | How it's actually tested |
| The appliance itself (web app, API, OS, containers) | No | Deploy the same shipping OVA or VM image into an ordinary lab |
| The isolation and boundary controls | Partially | Architecture and configuration review, plus a boundary test where a representative network is available |
Building representative evidence
- Deploy the exact shipping OVA or VM appliance into your own virtualisation stack. It's the same software either way. A hospital's hypervisor isn't testing anything the tester's own isn't.
- Ask whether a client site, or a client-provided loaner environment, can host a real test window, even briefly, for the boundary controls specifically.
- Where neither is available, scope two pieces of work rather than one: a full test of the appliance itself, plus a focused architecture and configuration review of the isolation boundary, documented as a reviewed assumption rather than a tested control.
A pattern we see often: a SaMD company building an AI-assisted diagnostic platform, shipping both a cloud API and a VM appliance packaged for air-gapped hospital and clinic deployment, asked us almost exactly this question. They didn't have the infrastructure to simulate an on-premises network internally, and assumed that meant the appliance itself couldn't be properly tested either. The fastest path turned out to be treating the appliance and the isolation as two different pieces of evidence, not one blocked test. The appliance got tested properly, on schedule. The isolation became a scoped architecture review, clearly labelled as such.
Keep it a delta, not a rebuild
If the cloud build and the VM appliance share the same core APIs and architecture, deliberately, you're only testing what's different between them each time, not the whole surface twice. That only works if the two builds are kept in sync on purpose. Left to drift, a cloud-only patch or a config change made just for the on-premises package quietly turns one evidence base into two, and nobody decided that.
Where this goes wrong
Testing only the cloud build and assuming the VM appliance inherits the same assurance, when it's often packaged by a different process entirely. Treating "it's air-gapped" as a control in itself rather than an assumption that still needs occasional verification. Letting the appliance and the cloud build drift apart architecturally, which quietly doubles the test programme without anyone choosing that. And skipping the retest after a design change made under deadline pressure, when the FDA's guidance explicitly expects retesting after anything material.
Free resources
System Boundaries: Who Controls What: a shared-responsibility table and example boundary diagram, useful for documenting exactly where the isolation assumption sits.
Free download
System Boundaries Guide
Essential Guide to SaMD and MedTech Device Security: a broader primer if you're still scoping what needs testing across deployment models.
Free download
Essential Guide to SaMD and MedTech Device Security
Book a review
In 30 minutes, we'll:
- Work out which parts of your deployment genuinely need network-level replication, and which don't
- Scope a test of your appliance alongside a focused review of the isolation boundary
- Agree how to keep your cloud and on-premises builds in sync so future testing stays a delta, not a rebuild
FAQs
Can you really test a VM appliance without a live air-gapped network?
Yes, for most of it. The application inside the appliance is the same software regardless of network topology, so it can be deployed and tested in an ordinary lab. Only the isolation and boundary controls themselves need something closer to the real network.
Does FDA's guidance require testing on the actual production hardware?
It expects a production-equivalent configuration, the build that will actually ship, rather than an early prototype. That's about the software and configuration matching what ships, not about physically replicating a hospital's network.
What's the practical difference between testing the appliance and testing the isolation?
Testing the appliance means attacking the web app, API, OS and containers to find exploitable issues. Testing the isolation means checking whether the boundary controls (firewall rules, one-way flows, no outbound access) actually hold, which is closer to an architecture and configuration review than a traditional penetration test.
Do we need a completely separate pen test for each deployment model?
Not from scratch, provided the architecture stays consistent between them. Keep the cloud and on-premises builds in sync and each round of testing only needs to cover what's genuinely different.
What if our timeline is too tight for a live boundary test?
Scope a focused architecture and configuration review of the isolation boundary instead, documented clearly as a reviewed assumption rather than a tested control, alongside a full test of the appliance itself.
How does this affect retesting after design changes?
FDA's guidance expects a retest after any material change. Keeping the appliance and cloud builds architecturally in sync means a change to one doesn't silently invalidate the evidence for the other.
Related reading
- Build once, submit everywhere: architecting cybersecurity evidence to serve FDA, EU MDR and NHS DTAC without starting over for each.
- Hands-on or hands-off? Choosing how much of your MDR/510(k) work to outsource: how much delivery support to bring in for programmes like this one.
- Adaptix case study: a worked example of a connected medical device manufacturer's security testing programme.
