DTR Vantage

Credentials

• The operator's password is never stored. Anything Vantage does as you (an agent deploy, a Hyper-V change, a Windows Update install, an inventory read by delegation) takes your password for that action, holds it in memory, hands it to the child process over standard input, never as a command-line argument, and forgets it. The audit line records your user name and the words "credential not stored".
• Remote Desktop and VM consoles carry no password. Remote Desktop is a downloaded .rdp file naming the server and you; the sign-in is your own Windows session. The Hyper-V browser console posts your password into the gateway's own form for that connection only; it is on no page element and in no address.
• The per-server agent secret is issued exactly once, at enrolment or redeploy, by that one endpoint, and never returned by any read. Agent reports are signed with it (HMAC over the UTF-8 bytes). A rotation keeps a grace window on the previous secret so a server mid-rotation is never locked out; a rotation is never made before the new path is proven.
• Stored credentials never come back out. Appliance accounts, the per-pool XenAPI credential and the MaxMind licence key are encrypted with a machine-local key on the server and are never returned by a read endpoint; a status says only that one is stored.
• Two NetScaler accounts, on purpose. Monitoring reads with a read-only account. Configuration uses a separate read-write account that exists only where NetScaler Configuration is licensed and is used only for an explicit administrator action, never by collection.

Certificates and TLS

• Pinned before a credential is sent. A XenServer coordinator's certificate and a NetScaler's NITRO certificate are recorded by SHA-256 on first use. A changed certificate is refused, and the credential is not sent, until an administrator accepts the new one by hand. A changed pin is never re-learned automatically, and never in bulk.
• No bypass switch. There is deliberately no "skip TLS verification" option anywhere: not for appliances, not for pools, not for the licensing portal, not in the connection test. A certificate this server does not trust is a refusal in words with the two ways to trust it.
• The portal's certificate is verified against the machine's store plus the public roots (certifi where installed); the download's SHA-256 is checked before a package is offered for install.
• ACME: the External Account Binding credential is never stored; the certificate's private key is generated on the appliance and never passes through Vantage.

What leaves your network, and when

• Nothing on a timer, with one opt-in exception. The dashboard contacts the licensing portal only when an administrator presses Activate online, Check for updates or Download. The one timed contact is the company's Uptime page, off by default: when switched on, the external targets' state, latency and figures go to uptime.dtrvantage.com on the cadence you set, and nothing else.
• Licences verify offline. A key is an Ed25519-signed file checked against an embedded public key; there is no phone-home and no licence server in the request path. The consequence, stated plainly: a revoked key keeps working on its installation until it expires; revocation refuses updates and re-issues, it does not reach into a dashboard.
• Geolocation is local first. Address lookups read a MaxMind database on the server; the online provider is off by default and, when on, sends only the address, budgeted per pass.
• HDX Insight and syslog are decoded and stored on your host. No record is relayed anywhere.

The Windows agent

• Deliberately not an administrator. The agent runs as a shared least-privilege service account, so a password stored for monitoring is not a password worth stealing. Running it as SYSTEM was considered and rejected.
• Granted exactly what its collectors need, and the deploy log says so: Event Log Readers for the Security log, Remote Management Users for the scheduled inventory's fallback identity. One opt-in widening: the Hyper-V collector adds the account to Hyper-V Administrators on that host only, because nothing narrower lets an account enumerate guests; it is granted only when that collector is ticked and the log says the group can also control guests.
• Windows Update scans run as a scheduled task as SYSTEM, because the Windows Update Agent refuses a search to a non-administrator; the agent may start that task and read its file, nothing more. Installs remain an action taken as the operator.
• The agentless inventory installs nothing and writes nothing on the target. It reads over WinRM, on demand as you by delegation or on a schedule as the server's own identity.
• Deployment is as you, over WinRM, with your own credential for that run; the agent is a signed-report PowerShell service, not a binary from a third party.

Actions and audit

• Reading is licensed apart from changing. Without a management module the product reads; with one, every change is a specific, confirmed action by an administrator or operator, in the system's own API (NITRO, XenAPI, the Hyper-V cmdlets), never a scraped GUI.
• Every action is an audit line naming who, what, and the system's own answer; NetScaler changes are also a row in a configuration log with the appliance's words.
• Data-destroying actions are administrator-only (VM delete, snapshot revert, host power, Hyper-V remove) and confirmed in words first.
• Roles: viewer, operator, administrator, mapped from AD groups; administrator-only controls are hidden in every place they appear, not just one.

The update path

• An update is applied by a system task apart from the service, from a package whose SHA-256 was verified at download: stop, back up, deploy, restart, roll back on failure, and report the outcome to the page. The task's inbox is writable by SYSTEM and Administrators only.
• The updater never touches what it does not ship: it does not install the optional remote-desktop gateway, does not change the site's certificate, and applies from a file you can inspect first.

Deployment footprint

• One Windows Server VM with IIS in front. Nothing is installed on the appliances or pools; one small agent per Windows server. SQLite files on the box, backed up by the updater.
• The optional Hyper-V browser console is a separate product (Myrtille, Apache 2.0) with its own installer, offered only by the setup on request, never by an update; where it rebinds the site's certificate, the setup puts yours back.

Reporting a vulnerability

Write to dtrvantage@dtrnetworks.com. The same address is published at /.well-known/security.txt (RFC 9116), so a researcher who never read this page still finds it.

What happens next: you hear back from a person within one business day, and a confirmed finding is fixed in the next build rather than queued behind features. You are told when the fix ships and which build carries it, and credited in the release notes if you want to be. There is no bounty programme; there is a reply, a fix and a thank-you. Please give us the chance to ship the fix before publishing details.

How fast a fix reaches an installation

Every change ships as a numbered, cumulative build, so a security fix is never held for a release train. A fix is published to the dev channel first, where DTR's own estate and the accounts marked early-access run it; when it has held there it is released to everyone. Each installation then takes it from its own Settings page (Check for updates, Install now) or from the update zip by hand, applied by a system task with backup and rollback. Nothing is pushed into a customer's server without an administrator asking, which is why this page and the release notes say plainly which build carries a fix.

What it is built on

Not a full software bill of materials; the pinned list for any build is yours on request. The dashboard is Python 3.12 on Windows Server with these packages, installed from PyPI or from wheels you stage offline:

Each build's installer names the packages it installs, and a build that updates a dependency says so in its notes. We follow the advisories for the packages above; a vulnerable dependency is handled as a vulnerability report, on the cadence described above.

Certifications, stated plainly

DTR Vantage is not SOC 2 or ISO 27001 audited, and we do not plan to be at this size. What stands in its place is the design on this page: nothing of yours in a cloud we run, no operator password stored, no TLS bypass, an agent that is not an administrator, every action audited on your own server. Because the product runs entirely inside your network, the controls an audit would attest to on our side largely do not exist on our side; they are yours, on the VM you installed.

What we support when your process needs evidence: your security questionnaire answered from this page and the docs; a walkthrough of the code, which is Python and PowerShell on your own server; a penetration test against your own installation, with our help reading the results; the audit log and the configuration log as exports. If an audited attestation is a hard requirement, say so early and we will tell you honestly whether we can meet it.

Questions we are asked

Can you see our data? No. There is no cloud tenant; the only thing that reaches us is what you send: an activation code, a licence check when you press Check for updates, and the external Uptime targets if you publish them.

What if a Vantage server is compromised? It holds the appliance and pool credentials encrypted with a key on that machine, and the agent secrets; it holds no operator password. The NetScaler configuration account is worth rotating first; the monitoring accounts are read-only by design.

Can we review the code? The dashboard is Python and PowerShell on your own server; the agent is a readable script. Ask.