Claims of "no‑logs" remain the most scrutinized promise a VPN service can make. This updated November 2026 guide shows engineers and operators of VPN services how to turn that marketing claim into verifiable technical evidence. It covers reproducible build pipelines, memory‑only server runtimes, modern confidential‑computing attestation, public transparency logs, software bill of materials (SBOMs), and a repeatable audit process tuned for the toolset widely in production in 2026.

Who this is for: VPN engineers, security leads, and privacy‑minded operators who are responsible for technical evidence that session data is non‑persistent and that operational software matches published source artifacts.

Why this matters now (context, 2026)

By late 2026, confidential computing and provenance tooling have moved from niche to mainstream: major cloud providers expose attestation APIs for confidential VMs, reproducible‑build toolchains are widely available, and transparency services such as Sigstore (cosign + Rekor) are commonly used to publish build artifacts. Regulators and courts increasingly ask for demonstrable evidence rather than assertions; independent auditors and privacy researchers expect machine‑readable proofs (attestation quotes, SBOMs, reproducible hashes) when evaluating a provider's "no‑logs" posture.

That landscape creates opportunity: operators who adopt reproducible builds, ephemeral memory‑only runtimes, and hardware‑backed attestation can produce granular, publicly verifiable records auditors can re‑run and validate. This guide updates operational recommendations, tooling patterns, and audit cadence for the current environment.

Prerequisites / What you should know first

  • Familiarity with reproducible‑build concepts and at least one toolchain (Nix, Bazel with deterministic build rules, or Gitian).
  • Experience with container orchestration or instance orchestration (Kubernetes, Nomad, or cloud instance fleets), and CI/CD integration.
  • Access to a secret manager (cloud KMS, HashiCorp Vault) and at least one attestation-capable platform (TPM on bare metal or cloud confidential VM such as Azure Confidential VMs / Google Confidential VMs / equivalent).
  • Basic familiarity with Sigstore (cosign + Rekor), in‑toto provenance, and SBOM formats (SPDX, CycloneDX).

Core components — updated for 2026

  1. Deterministic, reproducible build pipeline with signed artifacts and published provenance (in‑toto + cosign/rektor).
  2. Ephemeral, memory‑only server runtime: no long‑term session persistence, image reprovisioning model, sealed short‑lived keys.
  3. Hardware‑backed remote attestation (TPM PCRs or cloud confidential VM attestation) integrated into automated provisioning.
  4. Public transparency logs for builds, attestations, and operational manifests; SBOM publishing for supply‑chain visibility.
  5. Continuous automated verification plus periodic third‑party audits and public audit digests.

Step 1 — Make builds reproducible and publish signed provenance

Why: Reproducible builds let any third party confirm that the binary you run was produced from the source you published. Provenance (in‑toto) and signed artifacts allow auditors to bind runtime measurements to published source.

  1. Choose a reproducible toolchain and lock the environment.
    • Options: Nix flakes, Bazel with hermetic toolchains, or Gitian descriptors. The critical requirement is a deterministic build environment — pinned compilers, pinned libraries, deterministic timestamps or normalization.
  2. Produce provenance and SBOMs.
    • Generate an in‑toto layout and link each build step. Emit an SBOM (SPDX or CycloneDX) for the built image and its transitive dependencies.
  3. Sign and publish artifacts.
    • Use cosign (or equivalent) to sign containers and binaries; publish signatures and provenance to Rekor (Sigstore). Consider keyless signing where appropriate to reduce long‑term key risk, while retaining an offline root signing key for critical steps.
  4. Make build metadata reproducible and auditable.
    • Publish commit hashes, build recipes, deterministic hashes (SHA‑256/512), SBOMs, and in‑toto provenance records to a public location. Push those records to one or more append‑only transparency logs; mirror to a second log to reduce single‑log risk.

Actionable example: In CI, create a reproducible artifact, produce an in‑toto statement linking source → compiler → linker → artifact, generate SPDX SBOM, cosign the artifact, and push signatures+provenance to Rekor. Store a copy of the build recipe and SBOM in the project's public repository for auditors to reproduce locally.

Step 2 — Design runtime servers to be ephemeral and memory‑only

Why: Removing persistent session storage on disk reduces the chance that a legal demand or attacker can recover historical session records. Ephemeral design makes the claim "we don't retain logs" testable.

  1. Boot and mount strategy.
    • Build images so /var, /tmp, and other stateful paths mount on tmpfs or ephemeral overlayfs. On clouds, use instance ephemeral disks that are wiped at terminate.
  2. Secrets lifecycle.
    • Don’t bake long‑lived private keys into images. Store long‑term material only in an offline root or KMS; provision short‑lived keys at boot (TTL minutes/hours) using the attestation flow described below. Rotate keys on every boot.
  3. Memory‑first logging and telemetry.
    • Configure telemetry agents (OpenTelemetry) to hold data in memory ring buffers and export to a controlled collector. Persist only minimal scrubbed diagnostics — policies for scrub/retention must be explicit and auditable.
  4. Instance lifecycle automation.
    • Prefer replace‑rather‑than‑patch: automated reprovisioning from a fresh signed image. Set instance TTLs to short windows appropriate for your scale (hours to days). Use blue/green or draining patterns to minimize session disruption.

Step 3 — Hardware and remote attestation (2026 practices)

Why: Attestation cryptographically ties a running instance to a measured image and configuration. In 2026, mainstream options make this practical for many deployments.

  1. Choose your attestation model.
    • TPM + UEFI Secure Boot for bare metal or dedicated hosts. Use tpm2-tools and tpm2‑pkcs11 for sealing and unsealing secrets.
    • Confidential VMs (cloud): Azure Confidential VMs, Google Confidential VMs, and cloud providers’ attestation APIs are commonly available. Use vendor attestation APIs to obtain signed quotes or measurement statements.
  2. Implement an attestation workflow.
    1. On boot, the host produces an attestation quote (TPM PCRs or enclave measurement) and a tamper‑evident nonce.
    2. Control plane validates the quote against expected measurements derived from the published reproducible artifact hash and in‑toto layout.
    3. On success, control plane issues ephemeral credentials (short TTL TLS certs, WireGuard keys) and records the attestation in the transparency log along with the issued credential fingerprint.
  3. Hardening and chaining.
    • Bind provisioning to multiple evidence points: image hash, SBOM fingerprint, and runtime attestation. Implement key‑unseal policies that require multiple measurements (PCRs) to reduce risk from single component tampering.
  4. Tooling notes.
    • Use vendor SDKs for cloud attestation and middleware libraries (OpenEnclave, Nitro, or platform SDKs). Keep the attestation verification policy public and machine‑readable so auditors can reuse it.

Step 4 — Publish verifiable operational proofs and SBOMs

Why: Proofs let third parties replay and validate the chain from source to runtime. Publishing SBOMs improves supply‑chain transparency and helps auditors spot suspicious dependencies.

  1. What to publish (machine‑readable whenever possible):
    • Reproducible build metadata: commit hash, build recipe, build environment manifest, deterministic artifact hashes.
    • SBOM for every published image (SPDX/CycloneDX).
    • In‑toto provenance statements linking build steps.
    • Attestation records: quotes, nonce, measurement, and issued ephemeral credential fingerprint.
    • Operational manifest: which images were active, instance IDs (hashed), region, timestamps, reason codes for replacements.
  2. Where to publish:
    • Primary: a public repository and a transparency log (Sigstore/Rekor or a self‑hosted equivalent). Mirror to a second log/service to avoid single‑point trust.
  3. Privacy balance:
    • Publish enough operational context for auditors (machine‑readable, time‑bound records) while avoiding release of user‑identifying data. Well‑defined redaction rules are part of a credible audit process.

Step 5 — Build a repeatable audit process (continuous + periodic)

Why: A single verification is useful, but sustained confidence comes from repeated checks and independent validation.

  1. Automated continuous verification.
    • CI jobs periodically re‑run reproducible builds on independent builders, verify recorded artifact hashes in the transparency log, validate attestation measurements against published build hashes, and check SBOMs for new risky dependencies.
  2. Third‑party audits and spot checks.
    • Contract independent security firms for live spot checks and full‑scope audits. Provide auditors with public evidence (provenance, attestation records) and, under NDA, short‑lived test credentials to observe runtime behavior.
  3. Public audit digests.
    • Publish an audit summary with scope, timeframe, and remediation steps. For issues that must remain confidential, publish technical appendices that allow verification of core claims without exposing sensitive details.
  4. Suggested cadence (2026):
    • Continuous: automated verification and transparency log monitoring.
    • Weekly: rebuild and re‑sign images from source in CI; publish any changes to SBOMs.
    • Monthly: spot‑check attestation records and instance manifests.
    • Quarterly: independent third‑party audit of controls and sampling of runtime instances.
    • Annually: full supply‑chain and firmware audit (where feasible) to validate hardware and vendor relationships.

Common mistakes and pitfalls

  • Embedding persistent secrets in images. Even encrypted keys stored in images create a long‑term risk if the decryption material is later exposed.
  • Publishing attestations without provenance. An attestation quote is only useful if auditors can map the measurement to a published, reproducible artifact.
  • Relying on a single transparency log. Mirror to multiple logs to avoid single‑point‑of‑trust failures.
  • Vague scrub policies. If diagnostics are “scrubbed,” publish the scrub rules and demonstrate them in audits — opaque redaction undermines trust.
  • Failure to secure the control plane. Control‑plane compromise can issue credentials or mass‑reprovision instances; treat control‑plane keys and signing processes as high‑value assets (use HSMs / threshold signing / multi‑party approval).

Pro tips (advanced)

  • Use threshold or multi‑party signing for critical artifact releases. Splitting key material between people or systems reduces insider risk for signed releases.
  • Publish SBOM diffs for each build to make supply‑chain changes easy for auditors to review.
  • Automate cross‑logging: push artifact records to multiple independent Rekor instances or mirror logs to independent services to strengthen non‑repudiation.
  • Instrument continuous attestation: periodically re‑attest running instances and rotate ephemeral keys more frequently during higher‑risk events (legal requests, threat intelligence incidents).
  • Maintain a hardened "witness" lab: an isolated environment auditors can use to reproduce builds and run attestation checks without needing access to production secrets.

Limitations — realistic expectations

The architecture described here raises the bar for anyone seeking historical session data, but it is not absolute. Kernel compromises, malicious firmware, or coerced insiders with control‑plane access remain realistic threats. The goal is not provable absolute privacy, but a defensible, verifiable posture that can be tested by third parties and presented as evidence in legal or regulatory contexts.

Conclusion — operationalizing "no‑logs" in 2026

In 2026, the technical ecosystem supports credible, auditable no‑logs claims if operators adopt reproducible builds, memory‑only runtimes, hardware attestation, SBOM publication, and repeatable audits. Practical implementation is an operational program: automation, frequent rebuilds, deliberate attestation, and public, machine‑readable proofs. Operators who implement these controls and publish verifiable evidence will be best positioned to withstand scrutiny from auditors, regulators, and privacy researchers.

FAQ

Does remote attestation alone prove you keep no logs?

No. Attestation proves the running image and measured state at a point in time. To make a no‑logs claim verifiable you need reproducible builds (to show the image matches source), ephemeral secret provisioning (so keys are short‑lived), and operational records (attestation quotes + credential fingerprints) published to a transparency log. The combination of these elements provides auditors the chain necessary to validate a no‑logs posture.

Can you rely solely on cloud provider attestation?

Cloud attestation APIs are practical and widely available, but they are one piece of the puzzle. Combine cloud attestation with reproducible builds, SBOMs, independent transparency logging, and control‑plane hardening. Also consider multi‑vendor attestation (where feasible) and mirroring proof records across logs to reduce single‑vendor trust assumptions.

How do I balance transparency with user privacy?

Publish machine‑readable proofs that are strictly operational (image hashes, attestation quotes, SBOMs). Avoid publishing user identifiers or raw telemetry. Define and publish a clear data‑redaction policy that auditors can examine; use hashed or salted instance IDs if you need a linkable identifier for operational auditing without exposing user data.

What should I expect auditors to ask for?

Auditors will request reproducible build artifacts and instructions, SBOMs, attestation records, control‑plane policies, and evidence of instance lifecycle automation. They will test whether an independent build reproduces the published artifact and whether attestation measurements match published hashes. Prepare both public evidence and a controlled process for limited, time‑boxed access to systems under NDA where necessary.

How often should I rebuild and re‑sign images?

Best practice in 2026 is continuous rebuilds triggered by security updates or weekly automated rebuilds from pinned sources. Rebuild frequency should balance operational cost with risk tolerance; frequent short rebuild cycles (weekly) combined with short TTL ephemeral credentials and continuous attestation produces a strong, auditable posture.