Security

ARROW is used to run security work, so it gets held to the standard it helps you enforce. This page is the whole picture in one place: who can reach what, what happens to the data you and your devices produce, how a device is erased between engagements, what gets logged, and how we test ourselves.

If you are evaluating ARROW, answering a client’s security questionnaire, or deciding what you are comfortable putting on a device, this page should answer most of it.

What the platform is, and who is who

A few words on this page mean specific things, and the boundaries between them are where most of the answers live.

The ARROW platform is the hosted system VTEM Labs runs. It holds your organization’s records, tracks your devices and requests, brokers access to them, and keeps the audit trail. The Console is the web interface onto that platform, which is what you are looking at when you sign in. The Console shows you the platform; it does not hold anything of its own.

Devices are the hardware and virtual appliances you deploy, and the tools that run on them, ARROW Manager and ARROW Control, run on the device rather than in the platform. ARROW Decrypt runs as a cluster you operate, on your own hardware or your own cloud account.

Two more, because this page leans on both. Your organization is you: the firm that holds the ARROW subscription, whose people sign in, and whose engagements these devices are deployed for. Your clients are the companies you have been engaged to test, whose networks those devices are plugged into. Your clients do not sign in to ARROW and hold no account in it. They appear in the platform only as the record your organization keeps of the engagement, which is a client name and the shipping and scheduling detail needed to get a device to the right place.

The line that matters: the platform runs your fleet, it does not hold your work. What you find on a client’s network lives on your devices and in the clusters you run, and it does not cross into the platform. Almost everything else on this page is downstream of that one boundary.

What is actually being protected

ARROW holds three different kinds of data, and they carry very different risk. Keeping them separate in your head is the fastest way to understand everything below.

Your organization’s records. Your client list, device requests, shipments, users, invoices. This is business data about running engagements, not the findings from them. It lives in the platform, it is scoped to your organization, and it is what most of the access control on this page is about.

What a device produces on a client’s network. Captures, tool output, credentials, notes, whatever your consultants put on the box. This is the sensitive material, and none of it enters the platform. It lives on the encrypted device, inside your VPN, and it is erased when the device comes back. The platform never receives it, so there is no copy of it to protect, subpoena, breach, or ask us to delete.

The platform’s own operational data. Health checks, connectivity state, job progress, metrics. Useful for keeping the fleet running and uninteresting to an attacker, but it still gets retention limits and redaction, because “boring” is not the same as “safe to keep forever.”

What is not a security control

Several things in ARROW look like security features and are not. Calling them security would be dishonest, and it would let you plan an engagement around a protection that is not there.

Out-of-band cellular is availability, not security. Every ARROW device carries a cellular modem, but it is a backup path rather than a second one running alongside the wired connection. While the wired network is healthy the modem sits in standby with no data session up, and the device brings it online only when the wired path fails or was never provided in the first place. That keeps you working, and it keeps a device from going unreachable on a client site. It does nothing to protect the host. What it does mean is that a device on failover has a route off the client’s network that the client’s own monitoring will not see, so the radio belongs in your rules of engagement rather than being treated as a detail of the hardware.

Being invisible on the client LAN is not authorization. An ARROW device opens no services on the network it is plugged into, so there is nothing to scan and nothing to log into locally. That reduces exposure. It is not permission. The client authorizes the deployment, in writing, before the device is placed.

None of the cryptography protects an open session. The disk encryption, the firmware password, the ARROW-signed boot chain, and the TPM sealing all address a device that has been taken or tampered with, and they are described in full below. None of them do anything about a device sitting powered on with a consultant’s session already open in front of whoever is standing next to it. That one is handling, not cryptography.

A green VPN health banner means the tunnel is up. It means the device can reach the network. It is not an integrity check, and it is not a statement that the device is uncompromised.

An audit log is evidence, not prevention. It tells you what happened. It does not stop anything. It is on this page under logging for what it is: the record you need afterwards.

Who can reach what

Signing in

There is no separate ARROW password to create, store, or leak. ARROW hands authentication to your organization’s identity provider, so people sign in with the credentials they already use for work, and the account lifecycle you already run - joiners, movers, leavers - is the one that governs ARROW. If your identity provider requires multi-factor authentication, ARROW enforces it at sign-in. Sessions expire on inactivity. See Signing In for the flow.

Roles and organizations

Every account carries a role, and the role decides what it can reach. Admins, Managers, and Users each see a different slice of the Console, and a feature outside your role is not merely hidden from the menu, it is not available to that account. See Users and Roles.

Above that sits the organization boundary. Your clients, devices, requests, results, and invoices are scoped to your organization and are not visible to another one. People who belong to more than one organization switch between them explicitly, and the switch changes what they can see.

Contractors are time-boxed by default

A contractor account is not a normal account with a note attached. It carries an expiry date, and multi-factor enrollment is mandatory before the account can do anything at all. Both are checked on every request, not only at login, so a contractor who authenticated at nine in the morning and whose access ends at noon stops being able to do anything at noon, with the token they already hold. Expiry, extension, and revocation are all recorded.

Reaching a device

Devices do not open themselves to the internet. Each one dials out and joins a private, encrypted VPN, and the on-device tools (ARROW Manager and ARROW Control) answer only over that VPN. There is no public address to find and no port to knock on.

Being on the VPN is not the same as being able to reach everything on it. A consultant can reach a device when they are assigned to it in the Console, and not otherwise. Assign someone and their access appears within a few minutes; unassign them and it is revoked the same way. Nobody writes a firewall rule by hand, and nobody has to remember to take access away at the end of an engagement.

Access is also one-way on purpose. You can reach a device over SSH, VNC, and other management protocols; the device can never open a connection back toward your workstation. That is the protection you want in this line of work: if a box you are testing from gets compromised, it cannot turn around and pivot into your own infrastructure. You can see the whole model, per person, in the Console. See Network Access Control.

Reaching the device over the VPN is the first gate, not the last. ARROW Manager and ARROW Control still require you to sign in, and sessions do not stay open indefinitely.

When we reach your account

A site administrator at VTEM Labs can start a support session as one of your users. We would rather say that plainly than leave you to discover it.

It is constrained on four sides. It requires site administrator privilege, which is held by a small number of people. The session carries an expiry, one hour by default, and can be revoked before that. Both the start and the end are written to the audit trail with who did it and why. And the user being impersonated is notified when it starts, so it is not something that can happen quietly.

Automation keys

When you connect ARROW to your own tooling, you create an API key with explicit scopes and a mandatory expiry date, at most a year out. A read-only integration never holds write access, and a forgotten key stops working on its own instead of outliving the person who made it.

Two details worth knowing. A key cannot be more powerful than the person who created it: scopes you do not hold yourself are dropped at creation, and the drop is recorded. And the key’s secret is shown to you exactly once, then stored only as a hash, so we cannot show it to you again and we cannot leak it back to you later. If you lose it, you rotate it. See API Keys.

What happens to your data

While it moves

Traffic to the platform runs over HTTPS. Device traffic runs over the encrypted VPN, and device management happens only over that tunnel. When you route a device’s own outbound traffic through the transparent proxy in ARROW Manager, it egresses through the VPN rather than leaking onto the network you are only visiting, which keeps the device’s activity deliberate and accounted for.

While it sits

The working storage inside every ARROW device is fully encrypted with LUKS, and the key is sealed to the device’s TPM against its verified boot chain rather than sitting on the disk or in someone’s password manager. The operating system, your tools, and everything you collect sit behind that. A device that is lost or seized while powered off is a locked box, and it stays one even for someone who takes the boot path apart. The full picture is under how a device is built.

On the platform side, the credentials and settings the platform needs in order to run are encrypted with a key held outside the database, and API key secrets are stored only as hashes. Backups are held in the platform’s object storage and are subject to the same access restrictions as the platform itself.

What stays with you

Engagement data does not enter the platform. That is a boundary in the design, not a default setting that could be turned the other way.

ARROW Decrypt is the clearest example, because it handles the worst of it: password hashes going in, recovered credentials coming out. Those stay in the cluster you operate. What ARROW Decrypt reports up to the platform is status only - fleet health, job progress, counts. Not your hashes, not your recovered passwords, not your wordlists. The Console shows you that a cluster is working; it is not a copy of what it is working on.

Inside ARROW Decrypt the handling is scoped to limit what a single mistake could expose. Usernames are separated from hashes on the way in, so a hash on its own does not carry the identity it belongs to, and every recovered password is scoped to the engagement it came from rather than pooled into one shared bucket. Results stay tied to the authorization that produced them.

The same principle applies on the device. What your consultants do on a device is theirs. The platform records that a device request was fulfilled, not what you found on the client’s network.

Links to built images

A download link for a built virtual appliance is a bearer credential: whoever holds it can pull the image until it expires. So links are minted by the platform, time-limited, and the act of minting one is recorded against the person who did it. Treat a link you have generated the way you would treat the image itself, and let it expire rather than parking it in a ticket.

Devices, from imaging to wipe

This is the part customers ask about most, so it is worth walking through end to end.

Locked down before it ships

A device is encrypted before it leaves us, not after it arrives, and the boot path around that encryption is locked down rather than left on vendor defaults.

The firmware is password protected, so the boot order and the security settings are not something a person with the device in front of them can quietly change. Secure Boot is enabled with ARROW’s own keys, and only ARROW’s: the shim, the bootloader, and the kernel are all signed by us, and the firmware is enrolled to trust those keys instead of the stock ones. A generic live USB does not boot on an ARROW device, because the firmware does not trust whoever signed it.

The disk key is then sealed to the onboard TPM 2.0 against the measured state of that boot chain, covering the firmware, the bootloader, and the Secure Boot configuration itself. The practical effect is the part worth understanding. The disk does not unlock because it is in the right machine; it unlocks because the machine booted the software it was supposed to boot. Change the firmware, swap the bootloader, or turn Secure Boot off in order to get around any of the above, and the measurement no longer matches, so the TPM does not release the key and the disk stays sealed. The attack this closes is the classic one of booting something else in order to read the disk.

During an engagement

The device holds your engagement data on its encrypted disk, reachable only over the VPN and only by the consultants assigned to it. It stays quiet on the client’s LAN. Where it can be deployed at all is a separate control with its own rules, covered in the Export and Deployment Policy.

Handling still matters, and no amount of cryptography substitutes for it:

Know where each device is, who deployed it, and who is responsible for retrieving it.
Do not leave a powered-on, unlocked device unattended.
Place the device where the engagement authorizes it to sit, and nowhere else.
Report a lost or stolen device immediately, so its access can be cut.

How a device is erased

A device does not carry one engagement’s data into the next. Closing out the engagement removes the device from your VPN, so it stops being able to reach anything and stops being reachable, and it queues the erase for when the hardware reaches us.

Optionally, before you ship it back. You can destroy the encryption from ARROW Manager while the device is still in your hands. It wipes the LUKS header on the encrypted storage, and that header holds the key material for the disk, so once it is gone the ciphertext on that disk cannot be decrypted by anyone, you or us included. Nothing has to be overwritten for that to be true, which is why it takes seconds rather than hours: the data is made unreadable by destroying the only thing that could ever have read it.

This step is yours to take rather than something that happens for you, and it is worth taking. It closes the one window the rest of this process cannot, which is the device in transit, out of your hands and not yet in ours. If the engagement was sensitive, or the return leg is long, or the client asked what happens to their data on the way back, do this before the box goes in the courier’s hands and you have a straight answer.

When the device reaches our rack. The disk is erased outright, whether or not you destroyed the encryption first. The device boots the wipe image over the network instead of its own operating system, using an ARROW-signed kernel. That image exists only to erase: it enumerates every fixed disk in the machine and issues a discard across the whole device, and where a controller refuses the discard it falls back to overwriting the head and tail of the disk, destroying the bootloader, the partition table, the filesystem signatures, and the backup partition table at the end of the disk. Then the device powers itself off.

Every step is reported while it happens, and a per-disk summary is recorded against the device request when it finishes: which disks were found, which method erased each one, how long it took, and any error. That summary is the record that the erase actually ran, on that device, on that date.

Nobody has to unbox the device, rack it deliberately, or start that pass by hand, and the instruction that starts it cannot be faked. The device ignores it entirely unless it is on our own rack network, and even there it checks the rack’s certificate against a fingerprint compiled into the device and verifies a signature on the instruction itself, with a five minute freshness window so a captured response cannot be replayed later. A network that merely looks like ours cannot talk one of your devices into wiping itself.

The policy around it

The controls around the on-rack pass matter as much as the erase itself, because that is the pass with a machine reporting back that can fail to report.

A device is not reissued until the wipe is confirmed. Confirmation means the device reported a completed summary, not that someone watched it boot.

An unconfirmed wipe is treated as a failed one. A device that starts the erase and then goes silent - a network drop, a power-off, a driver that did not load - would otherwise sit in exactly the same state as a device that has not come back yet, which is the dangerous ambiguity. The platform watches for it: an erase that was dispatched, has passed its grace window, and is no longer reporting progress gets flagged so a person investigates. Nothing is assumed to have worked.

Failures are loud, not silent. A disk the process could not erase is reported as failed with its error, and the device does not pass as wiped.

We describe what the process does rather than name a standard. If your client requires sanitization to a specific standard, or a signed certificate per device, raise it before the device ships and we will tell you what we can do for that engagement. What is described above is what runs by default.

Virtual appliances: what we cut off, and what you destroy

Everything above is about hardware we own and get back. A virtual appliance or cloud image is a different situation and it is worth being blunt about it: it runs in your hypervisor or your cloud account, on storage we cannot see and cannot reach. There is no rack for it to come back to.

What we do control is its access, and that ends automatically. When the request is marked complete, the appliance’s VPN membership is torn down: its peers are removed, and any web access routed to them goes with them. From that moment it is not on your ARROW network. It cannot reach the devices and services it could reach during the engagement, and nobody reaches it through ARROW. The virtual machine may still be sitting in your hypervisor, but it is no longer part of your fleet.

That does not depend on the appliance being shut down first. A virtual machine is yours, running in your environment, and closing out the engagement cuts its access whether it happens to be powered on at that moment or not.

Be clear about what that is, though. Cutting the VPN is access removal, not erasure. The disk is still there, in your environment, with whatever the engagement put on it.

So the destruction is yours to carry out. Your subscription terms require the appliance to be destroyed or decommissioned when the term ends, and that means deleting the virtual machine and its disks, along with any snapshots, clones, templates, and backups taken from it, which are the copies people forget. The same applies to any image you downloaded and kept.

What we can tell you is what left us. Download links for built images are minted by the platform and recorded, so there is a record of which images were produced for you and when. What happened to a copy after it landed in your environment is visible only to you.

If a device does not come back

Contact support the moment a device is unaccounted for. Its access is cut, which closes off its route to your network, and the encryption is what keeps the disk sealed in the meantime. Reporting it quickly is most of what turns a lost device into a non-event.

What we log, and what we do not

Two different things get called logging, and conflating them is how people end up either over-trusting or over-worrying. ARROW keeps them separate.

The audit trail

The audit trail is the security record: who did what, and when. It covers sign-ins and failed sign-ins, role and permission changes, organization membership changes, the full device request lifecycle including erase requested and erase completed, shipping label purchases and voids, API key creation, use, and deletion, support impersonation start and end, download links minted for built images, and data exports.

Two properties make it worth relying on. Each entry is signed, and each entry is chained to the one before it, so an entry that is altered or removed after the fact breaks the chain and shows up as broken rather than disappearing cleanly. Writing an audit entry never blocks or fails the operation it is recording, so the trail cannot be suppressed by making the system busy.

Audit records are readable only by administrators, are retained on a long horizon suited to answering questions years later, and can be forwarded to your own SIEM if you would rather hold your own copy.

Operational logs

Operational logs are the running commentary: jobs that ran, errors that were hit, connectivity that came and went. They are kept on a short horizon, days rather than years, because their value decays fast and their risk does not.

The retention has a deliberate safety catch. Shortening it is only honored while log shipping to your external log platform is confirmed healthy; if shipping is broken, the platform refuses to delete down to the short setting, because that would destroy the only remaining copy of the last few days at exactly the moment you might need it.

What never reaches a log

Passwords, API key secrets, and session tokens are redacted before anything is written, and email addresses are masked. This is enforced in the code that writes logs rather than left to the discipline of whoever adds the next log line.

What we deliberately do not record

We do not record the content of your work. The platform knows a device request was fulfilled; it does not know what you found on the client’s network. It knows an ARROW Decrypt job completed and how many hashes it recovered; it does not receive the passwords. It knows a device was erased; it does not have a copy of what was on it.

That is a design decision, not an oversight. The safest way to handle a client’s most sensitive material is to not be holding it.

How we test ourselves

ARROW is tested adversarially on a recurring cycle, repo by repo, by people whose job in that cycle is to break it. Each engagement records the commit it started from, so the next one knows exactly what changed since the last look and nothing drifts in unexamined. Findings from a previous cycle get re-tested in the next one and reported again if they are still open, which is the part that keeps a finding from quietly aging out. Fixes land in the code carrying the finding that prompted them, so the reason a control exists stays attached to it.

Releases run through an automated gate before they ship.

The reports themselves are not published. They contain working exploit chains against the current version, and publishing them would help exactly the wrong reader. If you need evidence of the program for a vendor review, contact support and ask what we can share under NDA.

Reporting a security problem

If you believe you have found a security issue in ARROW, or something about your account, your organization, or a device looks wrong, contact support straight away rather than investigating it yourself. That includes a device you cannot account for, a session or a change you did not make, and anything in the Console that does not match what you expect to see.

Fast reporting is most of the difference between a near miss and an incident. It is never the wrong call, and we would much rather look at ten things that turned out to be nothing.