Ship the box,
not the pentester.
PLDrop is a sealed appliance you plug into your own network. Testing then runs remotely through it — internal, web, external, API and Wi-Fi — as a single audited channel. Every session opens only on your MFA approval, lasts exactly as long as you allow, and can be cut mid-session. Every command is recorded, and there is no standing access — no approval, no open door.
- MODEL
- PLDrop D1
- WORKSPACE
- PLCage — sealed + supervised
- PLATFORM
- PLOS — hardened build
- RADIO
- PLWave — monitor + inject
- LINK
- PLLink encrypted tunnel
- AUDIT
- PLChain — hash-linked
- DATA
- your own S3 bucket
- SCOPE
- internal · web · external · API · Wi-Fi
- FORM
- appliance · AWS AMI · Docker
The unit is yours once it ships. It exposes no SSH port to the internet; it is reachable only through the tunnel we host.
Flights, hotels, travel days.
The testing was never the expensive part — getting a qualified tester in front of your network was, at every site, every time it had to be repeated. That line goes. No travel or accommodation is billed to you.
The evidence your assessor asks for.
Every session leaves a dated, per-command, tamper-evident record — who was approved, by whom, for how long, and exactly what they ran — readable from the console, while the engagement’s own captures and files sit in storage you own. The same run that saves the travel produces the proof.
The whole session is yours to control.
01 · The assigned tester opens an access request in the console. At this point no door on the device is open.
02 · The request lands with you. You approve it with MFA — or you do not. Without approval the sequence ends here.
03 · You choose how long the grant lasts — a few hours, a working week, or open-ended until you revoke it. The token is bound to this device and this tester, and expiry is enforced independently on the server and on the device.
04 · All test traffic runs over the tunnel — internal, web, external, API and Wi-Fi. Every command and every file transfer (name, size, sha256, direction) is recorded.
05 · End it whenever you want. Revocation is not a request to stop — the token is invalidated, the live socket is dropped mid-session, and the ephemeral user and key are removed. A long scan already running is the only thing that survives.
06 · Raw capture and scan output are removed from the unit — they were uploaded to your own S3 bucket first, and the local copy only goes once that upload is verified. What stays is the record of what was done, sealed in the chain.
A black box you post to your customer.
PLDrop is not a mini PC — it is a field unit built for one job. Same sealed box across the range; what changes is how it reaches the network and how much of the air it can hear.
- A2.4/5 GHz element · Wi-Fi test radio, monitor mode
- BTamper-evident seal
- CStatus lamps — tunnel · access · audit
- DRJ45 · your internal network
- ESerial plate · PLD-0001
One ethernet lead into your network. That is the only cable that carries anything, and nothing on the unit is exposed to the internet.
One channel. Four ways to put it there.
The consent gate, the token control and the your-bucket rule for engagement data are identical across every unit. What changes is how it reaches the network and how much of the spectrum it can hear.
PLDrop D1
the standard unit
Wired uplink into the network. The audited channel for internal, web, external and API work, with wireless testing on board.
AVAILABLE TO ORDERPLDrop W1
no cable run
Takes its own uplink over wireless instead of a patched port — for sites where nobody will give you a switch port, or where the run is impractical.
IN DEVELOPMENTPLDrop R1
wide spectrum
Listens far beyond Wi-Fi: sub-GHz, BLE, RFID and NFC, plus discovery of transmitters nobody logged. The premium unit, priced accordingly.
IN DEVELOPMENTPLDrop Virtual
AWS or Docker
The software build, run on your own infrastructure under licence. Everything the wired unit does except anything needing a radio.
AVAILABLE TO ORDER| Capability | PLDrop D1 | PLDrop W1 | PLDrop R1 | PLDrop Virtual |
|---|---|---|---|---|
| Uplink | Wired | Wireless | Wired | Your infrastructure |
| Internal · web · external · API | Yes | Yes | Yes | Yes |
| Wi-Fi testing | Yes | Yes | Yes | No — needs a radio |
| Sub-GHz · BLE · RFID · NFC | No | No | Yes | No — needs a radio |
| Rogue-transmitter discovery | No | No | Yes | No |
| Tamper-evident enclosure | Yes | Yes | Yes | Not applicable |
| Consent gate · lifetime · revoke | Yes | Yes | Yes | Yes |
| Captures and files to your own S3 bucket | Yes | Yes | Yes | Yes |
Units marked in development are not yet shipping — ask and we will tell you where they are and what the timeline looks like. Nothing is sold before it exists.
Seven things, and what each one is for.
One of them is the consultant’s workspace. The other six are in the same box and cannot be reached from inside it — which is the whole design.
The workspace the consultant is handed: one Linux, the tools, the engagement — and the whole of what they can reach. Everything else on this list sits outside it.
The workspaceThe supervision domain around that workspace. Everything the workspace does leaves it as metadata — the command, the file name, size, checksum and direction — and the rules that read it run in the control plane your console renders, not on the unit, flagging bulk movement out. Findings are formed from that metadata; your file contents never leave for us at all. Break-out and data-class recognition, and the same watch turned on your network, are in development.
Outside the workspaceNothing opens without your approval, and what opens closes on your terms — you set the lifetime and you can cut a live session.
Outside the workspaceThe unit only ever dials out. No port of ours faces the internet, so there is no inbound path to find.
Outside the workspaceWireless work handled on board, with monitor mode and injection — the capability the software-only build cannot offer.
Outside the workspaceEvery command and transfer is bound into a tamper-evident record. Remove a line and the record stops verifying.
Outside the workspaceOur own hardened build, provisioned per unit and rebuilt from scratch on “Destroy data”.
Outside the workspaceComponent-level detail, the build manifest and the platform it runs on are covered in the security pack under NDA — not on a public page.
You are trusting our consultant. The box does not.
Everything the consultant can reach is one sealed workspace: a Linux, the tools, and the engagement. The uplink, the keys, the record and the radio all sit outside it, and nothing inside can reach them. What does leave the workspace is a description of what it did — the command, the file’s name, size, checksum and direction — and that is what the supervision reads. Never the contents of your files.
The boundary itself is the thing being watched. A reach for the kernel underneath, for a device that was never part of the workspace, for the supervisor next door — none of that belongs to a penetration test, and from the outside all of it looks like one thing: an attempt to leave.
BOUNDARY PROBE · a process inside the workspace reached for a host device that is not part of it.
The engagement has a scope and the workspace is measured against it: hosts nobody agreed to, tooling aimed somewhere else, a tunnel opened to an endpoint that is not the consultant’s. A test is allowed to be aggressive. It is not allowed to be somewhere else.
OFF-SCOPE DESTINATION · traffic left the workspace toward a subnet outside the agreed range.
A penetration test moves findings, not file servers. Size, rate and direction are read together, because the giveaway is rarely a single file — it is the shape of the transfer.
BULK TRANSFER · 2.3 GB left the workspace, and nine more transfers inside five minutes.
Identity records, payment data, personnel files, credential stores. The intent is a label, never a copy — what would leave the box is the class, the count and the time, and the file it describes never leaves at all. Recognising the class is in development; what is live today is the volume watch beside it, which catches the same movement by size and rate.
IDENTITY RECORDS · a personal-data pattern was staged for transfer out of the workspace.
The unit reports what the workspace did as it does it, and the finding is formed from that in the same second. Nothing waits for a nightly job to notice.
It reaches your console with the session still open — what was seen, and when — and it is bound into the record on the way.
You cut the session from the console and the door closes on the device itself, not only in the interface.
PLGuard raises findings; it does not adjudicate them. Each one carries what was seen and when, so a person decides what it means — and nothing about raising it requires the data it refers to leave the box. The live watch is the volume rule, and its size and rate thresholds are agreed with you and set before the unit is powered on; the other three classes are in development, and theirs are agreed when they ship.
Then the unit turns around and watches everything else.
The supervision that faces the workspace will also face your network — catching what falls outside the penetration test entirely: data leaving, unexpected egress, out-of-scope scanning, and reporting it in the console. The unit already sits where it would need to sit, and the console already has the place to show it. This half is not shipping yet, and it is not part of what you are buying today.
Illustrative feed, showing the shape of a network finding rather than one this unit has raised — the network-facing half is in development. The transfer alerts described above are live today; each one is sealed onto the audit chain and shown in your console. The capture or file it refers to stays in your own S3 bucket.
Your data stays in your bucket.
You supply the storage. Everything the engagement produces — captures, scan output, the files that moved, the unit’s own reports — is written by the device straight into your own S3 bucket, and erased from the unit once it is there. We never receive it.
What reaches us is the record of what was done: the command as it was typed, and each transfer’s name, size, checksum and direction, sealed into the hash chain the console shows you. Never a file’s contents, never a capture, never what a command printed back. Anything typed into a command is in the record, because the command is — so treat it the way you would treat any audit log.
PLDrop in the field. It writes the engagement’s output over TLS to your bucket and deletes its local copy afterwards; whatever is still on disk at token expiry is erased by the wipe.
Your account, your region, your keys, scoped to one prefix. Nothing of ours reads what is in it — the unit writes, and the console never touches it. Hand the credentials to the unit directly and we never hold them at all.
- Packet captures and scan output
- Files transferred during the engagement
- Wi-Fi captures and attack artifacts
- The report files the unit produces
The unit also reports what it did. That report is sealed into the hash chain here, and the console renders it — which is why a line cannot be removed from it, by you or by us.
- Every command run, in sequence, as it was typed
- Each transfer’s name, size, sha256 and direction
- Scans, wipes and end-of-engagement teardowns
- Bulk-movement alerts raised on that metadata
Engagement over? The unit erases itself.
You press “Destroy data” in the console. The device wipes everything on it and rebuilds its system from scratch. What is left is a factory-state unit carrying no trace of the last engagement — return it, or use it for the next test.
The records in your bucket are yours; the destroy command does not touch them. How long you keep them is your decision.
- 01Command“Destroy data” — from the console, on your authority.
- 02WipeRaw capture, scan output, temporary keys and tokens are erased from the unit.
- 03Re-imageThe unit is re-provisioned back to its clean shipped state, and signs a teardown attestation the console verifies before it will call the unit clean.
- 04Clean unitReady for the next engagement, carrying nothing from the last one.
The cleanest answer to a data question is “we never receive it”.
Most vendor security reviews are long because the vendor holds your data. Ours is short, and it has exactly two halves. Your captures, your scan output, the files that moved and the unit’s reports go to storage you own and we never receive them. What we do hold is the record of what was done — metadata, sealed into a tamper-evident chain, with no column for raw bytes anywhere in the schema. Both halves are below, and the security pack carries the data-flow diagram that draws them.
- Device serial and hardware fingerprint
- Enrolment state and agent token
- Tunnel address and heartbeat status
- Which project and pentester a unit is assigned to
- Access requests, approvals and token lifetimes — including who approved or denied one
- The hash-chained record: each command as typed, each transfer’s name, size, sha256 and direction
- The end-of-day report built from that record, and the alerts raised on it
- Order, fulfilment and billing state
- Packet captures and scan output
- Files transferred during the engagement
- The output a command printed back
- Credentials or secrets a tool discovered on your network
- Any file’s contents, in any form
- Personal data from your estate — the records, files and datasets the testing touched
For regulated estates, internal testing is not optional.
Banks, payment processors and other regulated operators are required to test the inside of their networks — repeatedly, and with evidence. The cost has never been the test itself; it has been getting a qualified tester physically in front of the network, again and again, at every site.
Card payments
Internal and external penetration testing, plus periodic re-testing of the segmentation controls that keep the cardholder data environment isolated.
Segmentation is the test you have to repeat, and repeats are what travel makes expensive. A resident unit turns a re-test into a scheduled job.
Banking & financial services
Threat-led penetration testing for in-scope financial entities, with demonstrable control over who accessed what, when, and under whose authority.
Every session is approved by you, time-bounded by you, revocable by you, and written into a tamper-evident hash chain you can read from the console — the access record is the deliverable.
Payment messaging
Penetration testing of the secure zone, with evidence retained for attestation.
The secure zone rarely tolerates ad-hoc visitors. One sealed, consent-gated unit is easier to admit than a rotating cast of laptops.
Certified ISMS
Security testing carried out and evidenced as part of the control set.
The engagement produces the dated, per-command evidence the auditor asks to see, without you having to reconstruct it afterwards.
Essential & important entities
Policies on testing the effectiveness of network and information security measures.
Testing becomes something you run on a cadence rather than something you schedule around consultant travel.
Personal data
A process for regularly testing and evaluating the technical measures protecting personal data.
Regular testing that never copies the personal data out — findings leave the network, captures and files stay in your bucket.
Framework summaries are context, not legal advice. Scope, cadence and evidence format are set by your assessor, QSA or regulator — confirm them before relying on any of the above.
| Framework | Requirement | How PLDrop answers it |
|---|---|---|
| GDPR Art. 5(1)(c) | Data minimisation | The control plane holds device-management metadata and the audit record — metadata only, with no raw-bytes column in the schema. The engagement’s captures, files and output are never collected by us at all. |
| GDPR Art. 28 | Processor obligations | The personal data your testing touches is written to storage you own and control; we never receive it. Assess the audit record on its own terms — it holds the commands your testers ran, not the data those commands read. |
| GDPR Art. 32 | Security of processing | No standing access, MFA-gated sessions, customer-set token lifetimes with instant mid-session revocation, encrypted transport, and a hash-chained record of every action. |
| GDPR Ch. V (Art. 44+) | International transfers | The engagement’s captures and files never leave the bucket, account and region you nominate. The one flow to assess is the audit metadata reaching our control plane — named here rather than left for you to discover, and set out in full in the security pack. |
| KVKK (Türkiye) | Veri sorumlusu / işleyen | Same position as GDPR Art. 28: you remain veri sorumlusu, and we never receive the engagement’s data. Assess the audit metadata we do hold on the same footing as any logging processor. |
| ISO/IEC 27001:2022 · A.5.15 | Access control | Access exists only while a customer-approved token is valid; the ephemeral user and key are deleted on expiry. |
| ISO/IEC 27001:2022 · A.8.15 | Logging | Every command and transfer is logged into a tamper-evident hash chain, readable from the console for as long as you need it as evidence. |
| ISO/IEC 27001:2022 · A.8.10 | Information deletion | “Destroy data” wipes the unit and rebuilds its system; retention of what is already in your bucket is your decision, and the audit record is readable before it is closed. |
| ISO/IEC 27001:2022 · A.8.29 | Security testing in development | The engagement itself produces the dated, per-command evidence this control asks you to keep. |
| PCI DSS v4.0 · Req. 11.4 | Internal penetration testing | Scoped internal testing with a retained methodology, findings and an end-of-day report you own outright. |
The table above states which controls the product is built to answer. It is not a claim of certification. Where PyramidLedger holds a certificate, the scope and registration number are supplied with the security pack — ask and we will send it.
For vendor review we provide the data-flow diagram, the retention position, the access-control model, the destroy-and-re-image procedure, and any certificates in force. Because the engagement’s captures and files never reach us, the DPA is short: the only flow to assess is the audit metadata, and the diagram draws it.
Request the security packAnyone can claim it. These are the standards that check it.
A security product asking to sit inside your network should expect to be verified rather than believed. These are the schemes that do that for a device of this class, and what each one actually proves.
| Standard | What it proves |
|---|---|
| Common Criteria · ISO/IEC 15408 | An independent lab evaluates the product against its own stated security claims. This is the standard that answers “does the box actually do what the datasheet says”. |
| UKCA / CE · Radio Equipment Regulations | Conformity for placing radio-equipped hardware on the UK and EU market — safety, EMC and correct use of the wireless spectrum. |
| ETSI EN 303 645 | The baseline security expectations for connected devices: no default passwords, a disclosure route, secure update, minimised attack surface. |
| FIPS 140-3 | Validation of the cryptographic module itself, where a buyer requires validated crypto rather than merely correct crypto. |
| SOC 2 Type II | That the controls behind the Console operated effectively over a period, not merely that they existed on the day of the audit. |
| ISO/IEC 27001 | That the organisation running the service manages information security to a certified system — the operator, as distinct from the product. |
This table describes the schemes, not our holdings. Nothing here is a claim that PLDrop carries any of them today — where a certificate is in force, its scope and registration number arrive with the security pack.
You are putting a box on your internal network. Three guarantees.
Consent
No access without approval.
Every session opens on your MFA approval. Withhold it and the pentester cannot connect. You are the party holding the door.
Containment
No standing access.
A token lives exactly as long as you set it, and you can revoke it mid-session — the live socket is dropped, not just blocked. No SSH port faces the internet; the unit is reachable only through the tunnel we host.
Evidence
No silent access.
Every command and transfer is sealed into a hash chain as it happens, each line binding the one before it. Remove or edit a line and the chain stops verifying — the break is arithmetic, not a matter of trusting us. Read the whole of it from the console whenever you want.
Every line is bound to the last.
The audit record is tamper-evident: each line seals the hash of the one before it, so changing or deleting any of them stops the chain verifying — the break is arithmetic, not a matter of trusting us. It holds what was done, never what was in it: the command as typed, and each transfer’s name, size, checksum and direction.
| TIME | TYPE | EVENT | HASH | ← PREV |
|---|---|---|---|---|
| 09:41:02 | access | token minted · ttl 24h · pentester #7 | 9e02…44 | 0000…00 |
| 09:41:18 | ssh | session opened · via tunnel 100.64.0.9 | a7c1…d8 | 9e02…44 |
| 09:43:55 | cmd | nmap -sV 10.0.4.0/24 | 7f3a…c1 | a7c1…d8 |
| 10:02:11 | scp↑ | segment-notes.txt · 12 KB · sha256 ok | 2b8d…09 | 7f3a…c1 |
| 11:16:40 | cmd | smbclient -L //10.0.4.21 | c4e7…7a | 2b8d…09 |
| 09:41:02+1d | expiry | token expired · shell closed · scan kept | d1f0…b3 | c4e7…7a |
| 09:41:03+1d | wipe | device wiped + re-imaged · chain sealed | e83b…2f | d1f0…b3 |
Run the whole fleet from one console.
Your devices, access requests, live sessions, anomaly findings and reports — in one place. The console renders the record your units report; the captures and files themselves stay in your own S3 bucket. Approval and destruction both happen here.
| SERIAL | LOCATION | STATE | TOKEN |
|---|---|---|---|
| PLD-0001 | London · HQ | ACTIVE | 23:41:12 |
| PLD-0002 | Frankfurt · Data centre | ONLINE | — |
| PLD-0003 | Leeds · Plant | AWAITING APPROVAL | — |
| PLD-0004 | Depot · returned | WIPED | — |
One price. The device, and the first year of console included.
There is one product and one price. The only choice is whether it arrives as a unit you plug in or an image you run — and only the unit can do the wireless work.
all-inclusive · per unit · ships in ~3 months
After the first year, the console renews at $500 per unit per year. The device stays yours either way.
- First year of the PLDrop Console licence, included
- The consent gate: nothing opens without your approval, on a lifetime you set
- Live command view, revoke mid-session, stop a single tool
- Captures, files and reports straight to your own S3 bucket — we never receive them
PLDrop D1
The device — internal network and Wi-Fi
- PLDrop D1 field unit, sealed enclosure — posted to you
- Internal network testing over the tunnel: hosts, web, API
- Wi-Fi testing on board — monitor mode and injection
- Bulk data-movement alerting on transfer metadata, never on file contents
- Hardware warranty and replacement
PLDrop Virtual
The same thing without the radio
- AWS AMI or Docker image, on infrastructure you already run
- Internal network testing over the tunnel: hosts, web, API
- No Wi-Fi testing — that needs the hardware radio
- The same supervision rules, evaluated in the console you can see
- Nothing to ship, nothing to return
One unit is a real order. The seat and asset minimums in this market start at ten, twenty-five, a hundred and fifty.
We do not sell you a number of people. How many can work through a unit at once is a limit of the unit, not of the licence.
You are buying a device and a year of console, not signing a term.
The pre-order takes about a minute: pick the unit or the image, give the details the invoice needs, and pay by card on the provider’s own hosted page. Prefer a quotation and a purchase order? Ask instead — both routes are open.
A VAT invoice from PyramidLedger reaches you the moment the payment settles — no waiting for someone to raise it. Your order reference travels with it.
The early-bird unit ships in ~3 months. We write when it is on its way, and it ships with its serial already registered to you.
No travel, accommodation or on-site day rate appears on a PLDrop invoice — the work is done through the unit. $750 is the early-bird pre-order price for one unit with its first year of console; larger deployments and renewals are quoted. Card details are handled on the payment provider’s own hosted page and never reach pldrop.com. Invoicing is handled by PyramidLedger. Automatic licence renewal is still to come.