RFC 3161 Trusted Timestamps: Compliance Evidence an Assessor Can Verify Offline, Without the Vendor

NSAuditor AI Enterprise 0.33.0 ships opt-in RFC 3161 trusted timestamping — evidence packs an assessor verifies with stock openssl, offline, against a third party.

nsauditor-ai-ee-0-33-0-rfc-3161-trusted-timestamps-auditor-verifiable-evidence

Every pre-audit evidence pack arrives with an asterisk the vendor rarely prints: trust us that this is what the scan produced. For most of the compliance tooling market that asterisk is load-bearing. Ask how you would prove a report was not altered between generation and submission, and the answer routes through the vendor’s own platform — their hashes, their console, their word.

NSAuditor AI Enterprise 0.33.0, released 7 August 2026 alongside Community Edition 0.2.37 and agent-skill 0.2.35, removes the vendor from that sentence.

What shipped: RFC 3161 trusted timestamping, reachable and opt-in

Set a single environment variable — NSAUDITOR_TSA_URL — to a Time-Stamp Authority of your own choosing, and every artifact in the compliance evidence pack acquires an RFC 3161 timestamp-token sidecar: the compliance report, the scope attestation, and the chain-of-custody record.

The design decision worth noting is the one that isn’t a convenience. NSAUDITOR_TSA_URL has no default and never will. Unset means the capability is absent — it does not silently mean “use ours.” A timestamp is an outbound call to a third party, and for a scanner whose entire architecture is built on keeping customer data inside the customer’s network, that call is the operator’s decision to make. An air-gapped environment simply leaves the variable unset and loses nothing else.

The verification an assessor actually runs

The point of a trusted timestamp is that the party checking it does not need the party who produced it. The procedure NSAuditor documents for assessors is stock OpenSSL against the TSA’s own certificate chain:

openssl ts -verify -data scan_compliance_soc2.json \
  -in scan_compliance_soc2.json.tsr \
  -CAfile <tsa-ca>.pem -untrusted <tsa>.crt

No NSAuditor software is in that path. No account, no portal, no API key. The assessor’s own workstation, the artifact, the sidecar, and a certificate chain published by a third party.

Tested in both directions — which is the part that matters

On 7 August 2026, against a real public Time-Stamp Authority and through the binaries published to npm rather than a development build, a scan produced ten .tsr sidecars. The verification command returned Verification: OK on the compliance report, the scope attestation and the chain of custody.

Then a single byte was appended to one artifact, and the identical command returned Verification: FAILED.

That negative control is the whole claim. An OK on its own only demonstrates that a command executed successfully. The FAILED is what converts it into a statement about those exact bytes — the difference between a check that passes and a check that is capable of failing. For anyone who evaluates security tooling for a living, that distinction is the review.

What else is in 0.33.0

  • A real operator environment surface. NSAUDITOR_* now populates eleven compliance options end-to-end, and Community Edition gains compliance attest, --sla-policy and --compliance-history — putting recurring-scan attestation, SLA and MTTR tracking, and multi-period evidence history on the command line.
  • Zero Data Exfiltration, restated as something auditable. Instead of a negative absolute that a single omission would falsify, NSAuditor now publishes a positive register of 17 enumerated outbound paths across six counterparty classes — each with its trigger, whether it is on by default, the class of data involved, and how to switch it off. The published table is generated from the same register the code reads, and held byte-identical to it, so the document cannot drift from the implementation.
  • Disclosures that reach the files a customer receives. Evidence-quality warnings now render above the verdict in the written report, and SLA failures reach the document an assessor reads rather than a JSON field nobody opens.
  • A frozen, honest signature-record schema. Every record carries algorithm and backend from the first record onward — deliberately fixed before wider reachability, because retrofitting algorithm agility after signatures exist in customer evidence archives breaks every auditor holding one.

Scale, unchanged

One command across AWS, Azure and GCP with all seven frameworks enabled evaluates 1,608 controls and returns seven auditor-shaped reports — not one report relabelled seven times. The frameworks: SOC 2 (AICPA TSC 2017), HIPAA Security Rule §164.312, NIST CSF 2.0, PCI DSS v4.0.1, ISO/IEC 27001:2022, CIS Controls v8, and GDPR Article 32 (security-of-processing infrastructure substrate, not GDPR compliance as such).

All seven coverage matrices are unchanged in this release, as is the plugin count at 28 Enterprise plugins — 27 cloud auditors spanning the three providers, plus a Zero Trust posture assessment scored from a network-host scan. 0.33.0 moves reachability and evidence integrity, not coverage.

Availability

Community Edition is MIT-licensed on npm as nsauditor-ai. Pro and Enterprise ship as @nsasoft/nsauditor-ai-ee and install alongside it. Enterprise 0.33.0 requires Community 0.2.37 or newer — the new entry points live in the Community package.

Everything runs on the customer’s own infrastructure: agentless, read-only credentials, no SaaS backend, no telemetry, no phone-home.

Product details: nsauditor.com/ai/enterprise · Pricing: nsauditor.com/ai/pricing