Infrastructure audit

Every VPN provider says it keeps no logs. Almost none of them give you a way to check. This page is the way to check ours: monthly reports describing the verifiable state of the VPN infrastructure, published as machine-readable documents signed by the host that produced them, with the keys and the full configuration published alongside.

Nothing on this page asks you to trust YMRTECH. Everything on it is either fetchable, signed, or published as source code you can read.

What this is, and what it is not. These reports are produced by the infrastructure they describe, not by an independent auditor. They are self-reported, cryptographically signed, dated, and published — which makes them checkable and hard to quietly revise, not independently verified. We do not hold a third-party audit, an accredited certification, or a SOC 2 report, and we do not claim one. See Limits — it is the most important section on this page.

1. The claims, and the artifact that backs each one

The policy behind these claims is at What We Log and Privacy. This page is the evidence.

1a. The other half: how this is actually run

Everything above is technical proof — signed artifacts a stranger can fetch and verify. That answers “does the claim hold?” It does not by itself answer “is anyone actually running this, or is it a clever script nobody maintains?”

There is a second half, and it is published too: the management system behind the infrastructure. Not a certificate — a written, dated, inspectable record of how the service is governed.

Start at the management system index — it opens with what the documents are for and states the position in one paragraph.

The relationship between the two halves. The technical audit is evidence; the management system is process. Neither substitutes for the other. A signed daily report proves the logging posture held; it does not prove anyone would respond correctly to an incident. A written incident-response plan says what would happen; until an incident exercises it, it is a plan and not a record — and the statement of applicability marks it partial for exactly that reason rather than claiming it as met.

We publish the awkward parts of both. The audit page admits the audit is self-reported. The management system records that one person operates the service, that there is no separation of duties, and that the whole thing is self-assessed — no external auditor has looked at any of it. What we refuse to say, and why, is set out in Standards & Claims.

2. Fetch it yourself

Two hosts each sign their own report — there is deliberately no central audit that could speak for both.

1
2
3
4
5
6
7
8
9
10
# three files: the report, its detached signature, and the accepted signer
curl -O https://vpn.ymrtech.com/logging-audit/logging-audit.json
curl -O https://vpn.ymrtech.com/logging-audit/logging-audit.json.sig
curl -O https://vpn.ymrtech.com/logging-audit/logging-audit.allowed_signers

# verify — no YMRTECH software, no YMRTECH server, just OpenSSH
ssh-keygen -Y verify \
  -f logging-audit.allowed_signers \
  -I logging-audit@vpn -n logging-audit \
  -s logging-audit.json.sig < logging-audit.json

A pass prints Good "logging-audit" signature for logging-audit@vpn with ED25519 key SHA256:…. Each report also carries its own signing_key block with the exact command, the key fingerprint, and the principal — so the recipe travels with the artifact instead of living in this page.

The same three commands verify a dated copy (history/<host>-<date>.json) or a monthly report (monthly/<YYYY-MM>.json): each file is signed in its own right, so any single day or month can be verified on its own, detached from the host that published it and from any summary quoting it.

ssh-keygen -Y verify works on Linux, macOS, Windows (OpenSSH ≥ 8.0), and inside containers. It is a stock tool: no account, no API key, no callback to us.

3. What is published, and how often

A dated copy is what makes a missing day distinguishable from a passing day. Without it, “the audit has nothing to say about the 3rd” and “the audit passed on the 3rd” look identical from outside.

What a monthly report contains

The roll-up asserts nothing it did not read: before summarising a day it re-verifies that day’s signature against the published signer file. A month that does not verify is reported as a month that does not verify.

4. What the checks actually assert

These are behavioural assertions, not config-file comparisons. The full procedure for each is published in the source; in outline:

Each check reports the evidence string it based its verdict on, so a reader can see why a day passed — not just that it did.

5. The monthly report — published state

6. Verifying without trusting this page

1. Fetch the artifacts from the host, not from this page. This page is a summary; the reports are the evidence. A summary that disagrees with the artifact is our bug.
2. Check the key fingerprint against two independent sources: the fingerprint printed inside the report, and the same key on the other host’s report. The fingerprints are published in monthly/index.json too, so a key swap is visible as a diff.

3. Check the code you can, and know where the boundary is. The deployment that runs the audit, the host definitions, the firewall, and the publication path are all in the public configuration repository. The audit’s generator is not — it lives in a non-public repository — so its correctness is not something we ask you to take on faith either: every check, its verdict, and the raw evidence string behind it are published in the signed artifact itself, and the signer’s key is published so a substituted report is detectable. We would rather state that boundary plainly than imply a source you cannot read. See the public-source boundary.

4. Check the dates you care about. Dated copies are kept for historyDays (90 days — the fleet keeps nothing longer than 90 days, and 90 still covers the previous month in full plus two months of margin). Ask for one from the month you care about and verify it directly.
5. Verify a hash you kept. Because closed months are frozen and hashed, a copy you saved last month must still match what we serve today. If it does not, that is the finding.

The public-source boundary

We publish most of our configuration, and we are explicit about the part we do not, because “read our source” is only a fair invitation if the source is actually readable.

Public (git.ymrtech.com/ymrtech/nix-config): every host definition, the firewall and network configuration, the WireGuard and AmneziaWG setup, the resolver and DNS policy, the monitoring and alerting stack, the Caddy publication path that serves these artifacts, and the CI workflows that build, verify and deploy them.

Not public (nix-config-private): the modules that make up the product perimeter — the client-facing VPN service, its client-isolation ACLs, its provisioning — the fleet’s internal address roster (which host answers on which address, in which role), the deception layer, and the audit’s own generator. The perimeter modules and the generator are withheld because they are the parts whose details would most directly help someone attack a customer or evade the audit. The roster and the deception layer are withheld because publishing either would hand over the map: which address is which role, and which of our hosts is a decoy.

What that costs you: you cannot audit our generator’s source, so you cannot independently confirm that it checks what we say it checks. What you can do is audit its behaviour — the published artifact names every check and prints the evidence behind each verdict, the results are signed with a key you can fingerprint, and the daily series is frozen per month and hash-chained through monthly/index.json. A generator that quietly stopped checking something would have to lie in a signed, dated, archived document in order to hide it. That is a weaker guarantee than open source, and we would rather you hear that from us than discover it.

Closing that gap is on the roadmap: the audit’s generator is separable from the product-perimeter modules, and publishing it alone would not expose anything about the client VPN design.

7. Limits

A verifiable claim that overstates itself is just a louder unverifiable claim. These are the limits, stated as plainly as the strongest claims above:

• The audit is self-reported. It runs on the very hosts it audits. A full compromise of a host could forge its report. What the design buys is that the report is signed, dated, published, mirrored off-host, and reproducible from published configuration — so tampering is detectable and a rewrite is visible. It is not the same thing as an independent check, and we do not dress it up as one.
• No third-party attestation, and no certification. YMRTECH has not been audited by an external party. We hold no ISO/IEC 27001 certificate, no SOC 2 report, and no accreditation of any kind, and we say so on purpose: claiming one we do not hold would be a misrepresentation, not marketing. For what we are working towards and the exact vocabulary we permit ourselves, see Standards & Claims.
• Some checks are stronger than others. The resolver and query-log checks are enforced and probed; the journal check is a pattern assertion over a window. Where a check is weak, the report says what it actually tested.
• Retention values are declared, not enforced by this audit. The report states what the configuration says. Enforcing it belongs to the components that own the data.
• A gap is reported as a gap. If a timer does not fire or a host is down, the month records a coverage gap. We would rather publish an incomplete month than a complete-looking one.
• A gap is attributed, not just counted. The report table reads the host’s own coverage.archive_starts and splits every missing day into the days before dated copies began to be retained (context, shown as a note) and the days after (a finding, flagged in red). September 2026 opens with a large gap for exactly this reason: dated retention began on 2026-09-18, so days 1–17 predate the archive rather than representing a host that failed to report.
• Telemetry is aggregate. Per-interface byte and peer counts, with no per-peer labels: enough to run a network fairly, not enough to describe a person.

8. Monthly reporting cadence and change log

The report set is generated on the infrastructure and re-published here as the site is deployed, so this page cannot show a month the infrastructure has not published.

Corrections to this page are made in the public site repository, where every change carries a commit, an author, and a review.