How the Versus Collector establishes trust, encrypts every connection, signs and verifies dispatched operations, and keeps device credentials inside your network.
The collector dials out to Versus; it never listens for inbound connections. Nothing to allow-list on the inbound side of your firewall, ever.
The collector verifies the gateway's certificate, then authenticates every request with a short-lived token signed by its enrollment key — no shared secret, no password.
Each collector's identity certificate is valid for 90 days, is scoped to that one collector alone, and is renewed automatically: from day 60 the collector asks Versus for a fresh certificate for the same identity, so nobody has to re-enroll on a schedule.
Every operation Versus sends a collector is individually signed and independently verified before execution — not just carried over an encrypted pipe.
A collector never executes an arbitrary command — only a fixed set of named operations it implements itself. In the default vault mode, device credentials are encrypted on the collector's own disk and never transmitted back to Versus in plaintext.
Before a collector can do anything, it has to prove it's allowed to connect at all. Enrollment is a one-time event that establishes a cryptographic identity — it is not a password or a long-lived API key.
Scoped to a specific site. Versus stores only the token's hash, never the plaintext, and shows the plaintext value exactly once, at creation.
Its private key never leaves the machine it's generated on. It builds a certificate signing request (CSR) carrying its self-chosen identifier.
Versus validates the token (exists, not revoked, not expired, within its allowed use count), verifies the CSR's signature proves possession of the private key, and confirms the requested identifier doesn't collide with an already-enrolled collector.
90 days, from a dedicated internal certificate authority reserved for collector identities — kept entirely separate from any CA used for your own TLS certificates managed through Versus.
A second enrollment attempt with the same token is rejected. From here on, the collector authenticates by signing a short-lived token with its enrollment key on every request — no shared password or API key in day-to-day operation.
Every message between a collector and Versus travels over outbound TLS on 443 that the collector always initiates, authenticated with a short-lived signed token. The control path is a WebSocket control channel the collector dials out and keeps open, over which it asks for the next unit of work and returns results; where that channel can't be established, the collector falls back to a per-call HTTPS long-poll — an authenticated request Versus holds open until there is work to hand back, after which the collector asks again. Either way Versus never opens a connection to the collector: every channel is one the collector created, and Versus can only hand work back on it.
Every Connection, Always
The collector verifies the gateway's certificate, then proves its own identity with a short-lived token it signs with its enrollment key — read from the verified token itself, never from anything the request body claims.
Collector identity certificates are deliberately short-lived — 90 days — rather than long-lived credentials that would sit as a standing risk if ever exposed.
--renew-now forces one immediately. The Collector Fleet page shows when renewal opens and when it last happened. A certificate that has already expired cannot be renewed — that collector is re-enrolled with a fresh token, deliberately, so an expiry is always re-authorized by a person. Requires collector 0.4.15 or later; older collectors keep working but do not renew.An encrypted connection isn't the whole story — each individual operation Versus sends to a collector is itself cryptographically signed and independently verified before the collector will act on it. That matters because it means a compromised or misconfigured piece of infrastructure sitting between "Versus decides to do something" and "the collector executes it" cannot forge or silently alter what actually gets executed.
Every dispatched operation carries a signature over a canonical representation of its contents — which device, which named operation, which parameters, which credential references, and a validity window. On receipt, the collector runs each dispatch through a fixed verification sequence before executing anything:
Any failure at any step is treated as a security event and reported back as a rejected result — never silently dropped, never executed on a best-effort basis.
Most work a collector does is a dispatched operation: a single named action — read virtual-server status, install a software image, check HA state — delivered as one signed task over the long-poll path above. The collector claims it, runs it through the verification sequence, resolves the credential locally according to its vault mode, executes it, and reports the result. This covers the overwhelming majority of day-to-day activity, and everything in Task Integrity applies to it.
Some work isn't a single action, though. Importing a device's full configuration, running a guided software upgrade, or pulling a configuration backup are long sequences of device I/O — hundreds of API calls, an interactive SSH session, a multi-gigabyte file transfer — that can't be expressed as one named operation. For a device that lives on the collector's network and is reachable only through it, these run over a workflow tunnel.
Either way, a workflow tunnel is still an outbound, certificate-authenticated connection the collector chose to open — never a port it exposes — and the credential rules in the next section apply to it exactly as they apply to dispatched operations.
Collectors upgrade themselves — there's no manual binary swap or reinstall required for routine updates.
This is usually the first question a security team asks, so it deserves a direct answer: in the default and recommended configuration, your device credentials are stored encrypted on the collector itself and are never transmitted back to Versus.
The collector supports three credential-handling modes:
Device credentials are encrypted with AES-256-GCM and sealed into a file on the collector's own local disk. The encryption key is derived at runtime from the collector's own enrollment identity — it's never written to disk itself, and a credential sealed this way is only decryptable by that specific collector. If a collector is lost or decommissioned without a backup of its sealed vault, credentials stored in it must be re-entered on a replacement — a deliberate tradeoff for not centralizing decryption capability anywhere else.
For environments that prefer to manage credentials centrally in Versus rather than per-collector, credentials are resolved from the device's stored credential and delivered to the collector fresh, at the moment of each dispatch — held in memory only for that one operation and cleared immediately after, never written to the collector's disk and never persisted anywhere for later replay.
For organizations with an existing enterprise secret manager, the collector fetches credentials directly from that system at dispatch time rather than storing them anywhere in the Versus product stack at all. Rather than typing connection details separately for every collector, Mode C reuses one of your existing Vault integrations (Secret Vault → Vault Sources) — pick which one from the collector's own page, and every credential lookup goes straight from that collector to your Vault using that integration's own AppRole authentication.
| Mode | Where the secret lives | Versus sees it in plaintext? | On collector disk? | Best for |
|---|---|---|---|---|
| Local Vault | Sealed on the collector (AES-256-GCM) | Once, at seed time — then never | Yes, encrypted | The default — creds stay on-network, no external dependency |
| Cloud-relayed | Versus database | On every dispatch (in memory, then cleared) | No | Central management when an on-collector store isn’t wanted |
| External secret manager | Your own Vault / CyberArk / AWS SM | Never at dispatch time | No | Shops with an existing enterprise secret manager as source of truth |
Regardless of mode, every credential reference is scoped — bound to a specific tenant, provider type, and optionally a specific list of devices — and that scope is enforced locally by the collector itself before it will ever hand a credential to a device driver. This is what stops a compromised or malicious instruction from a management-plane component from exfiltrating a credential by pointing it at an unexpected target: the collector's own local scope check refuses the request regardless of what the dispatch claims.
These three modes, and that local scope check, are the same for a workflow tunnel as for a dispatched operation. When a supported workflow (an import, an upgrade, a backup) runs over a tunnel, the collector resolves and injects the device credential exactly as it would for a single dispatch — so a Local Vault collector applies the credential inside your network and Versus never sees it on the way in for that device. The one exception is the raw-relay fallback for a device type with no collector credential mapping, where the credential is supplied cloud-side; wherever a mapping exists, injection is used and the credential stays local.
Mode is a per-collector setting, changeable at any time from that collector's page in Collector Fleet — no re-enrollment required. Saving a change publishes the new policy; the collector picks it up on its next configuration poll and restarts itself to apply it (a live process can't safely swap credential backends mid-dispatch), coming back up running the new mode typically within a minute.
Where the credential you type actually lives. When you set a device's credential — on creation, or by editing it later — that value is stored encrypted (AES-256, field-level) in Versus's own database, the same as it always has been. That's the master record: it's what lets you reuse an existing credential across devices, edit it later, and switch a collector between modes without retyping anything. What differs by mode is what happens in addition to that:
Everything a collector needs to keep operating — its enrollment identity, its trust material, and, in Local Vault mode, its sealed credentials — lives in one directory on the collector's own host, never on Versus's side. That's a direct consequence of the trust model above: Versus can't back up what it never has a copy of.
What's in there:
| File | What it is | Consequence if lost |
|---|---|---|
| collector.key.pem | This collector’s private key, generated at enrollment and never transmitted anywhere | Re-enrollment required — a new identity, new certificate, new enrollment token |
| collector.cert_chain.pem, ca_bundle.pem, trust.json | Issued certificate and trust material | Regenerated automatically on re-enrollment |
| vault.json | Local Vault (Mode A) sealed credentials | Every credential sealed on this collector must be re-entered (re-pushed automatically from the device record for devices whose site still points at this collector; anything seeded manually before that existed needs re-entry) |
| vault_policy.json, scopes.json | Current vault mode and Mode C scope state | Rebuilt automatically the next time the gateway pushes vault configuration |
| idempotency.db | Recent-dispatch dedup journal | Safe to lose — at worst, a retried operation that would have deduplicated instead re-executes, which every dispatch is already designed to tolerate |
The two that matter are collector.key.pem and vault.json. Losing the key means losing the collector's identity — the replacement comes back as a brand-new collector via re-enrollment, not a restored one. Losing vault.json on a Mode A collector means every credential it had sealed is gone from that host (though, per above, still recoverable automatically for any device whose site still routes to it, without you doing anything).
To back one up: copy that state directory using your own infrastructure backup tooling — Versus has no visibility into it to back it up for you, and no product feature does this on your behalf, deliberately, since a backup path Versus could reach would undermine the "only this collector can decrypt this" property Local Vault is built on.
To restore: put the backed-up directory back in place at the same path on the replacement host, then start the collector binary — it finds its existing identity and reconnects as the same collector, not a new enrollment. This only works if the replacement host is trusted the same way the original was (its disk should be protected the same way); restoring a collector's identity onto untrusted hardware defeats the point of per-collector-sealed credentials.
The collector does not accept or execute arbitrary commands from Versus — full stop. Every device interaction is one of a fixed, enumerable set of named operations implemented in the collector's own code for that specific device vendor (for example, "read virtual server status," "install a software image," "check HA state"). There is no operation that means "run whatever string you're given."
Where an operation legitimately needs a piece of caller-supplied data — a virtual server name, a rule name, a software version string — that value is validated against a strict allow-list pattern before it's used, rather than being trusted or merely checked for obviously dangerous characters. A device object name that doesn't match the expected shape is rejected before it ever reaches the device, which closes off command-injection-style attacks as a category rather than filtering them case by case.
From the Collector Fleet view, an administrator has three levers over a live collector, each with different intent:
| Action | What it does | When to use it |
|---|---|---|
| Drain | Stops new work from being routed to the collector; lets in-flight work finish; identity remains valid | Planned maintenance, host reboot, decommissioning on your own timeline |
| Undrain | Reverses a drain, resumes normal routing | Maintenance complete |
| Revoke | Immediately blocks new connections and new work; existing certificate can no longer establish a session | The collector (or its host) is no longer trusted |
| Probe | Checks whether a collector is currently reachable, based on recent heartbeat activity | Troubleshooting connectivity |
| Question | Answer |
|---|---|
| Does Versus’s cloud ever see my device passwords in plaintext? | Never on the way back — no mode ever sends a credential from the collector to Versus. On the way in, it depends on the mode: you type a device credential into Versus once, so Versus necessarily handles that plaintext at the moment it’s saved. In External Secret Manager mode that’s the end of it — Versus never touches the device credential itself again, only your Vault connection details. In Local Vault mode, Versus additionally decrypts and pushes it once, at seed time (device creation, a site change, or a credential edit), to seal into that collector’s local vault — after that, every dispatch resolves it entirely on the collector with nothing round-tripping to Versus. In Cloud-Relayed mode, Versus decrypts and includes it on every dispatch, not just once — the strongest ongoing guarantee is External Secret Manager mode, where Versus is never in the credential’s path at dispatch time at all. |
| Do complex workflows like imports, upgrades, and backups keep credentials local too? | Yes, on a Local Vault collector. Those workflows run over a tunnel the collector dials outbound; for supported device types the collector injects the device credential from its own vault at the point of connection, so the credential is applied inside your network and never travels from Versus for that device — the same guarantee as a single dispatched operation. The only exception is a device type with no collector credential mapping, where the tunnel relays bytes and the credential is supplied cloud-side, exactly as for a device Versus can already reach directly. |
| Can a compromised Versus account push arbitrary commands to my devices? | No — the collector only ever executes one of its own fixed, named operations, never a caller-supplied command string, regardless of what a dispatch instructs. |
| What stops someone from intercepting and replaying a captured operation? | Every dispatch is individually signed and checked against a replay history on the collector; a previously-seen dispatch is rejected outright, independent of the encrypted transport it traveled over. |
| Does the collector need any inbound firewall rule? | No — it only ever makes outbound connections. |
| How fast can I cut off a collector I no longer trust? | Revocation blocks new connections and new work immediately. If you need to guarantee an already-open connection stops instantly, pair revocation with blocking that host’s network egress. |
| What happens to my devices if the collector loses connectivity? | Nothing changes on the device side — the collector simply reconnects with backoff once the path is restored, and any in-flight orchestration resumes from its last safe checkpoint rather than guessing at what happened while disconnected. |