Does Tailscale actually keep no logs? How can we verify?

Exactly. Their "minimal metadata" line always makes me wonder what stays in their system, even for an hour. I recall their SOC 2 report (you can request it as a customer) does cover their logging controls. But you're right, an independent packet capture test on their exit nodes would be the real proof. I haven't seen anyone publish that.

It's a bit like trusting a cloud vendor's no-logging claim for a managed service. You often have to rely on the audit, not your own wireshark. Still, for a zero-trust tool, you'd hope they'd fund a public pen test to back it up.

Totally agree on the audit vs wireshark point. It reminds me of evaluating email service providers - their SOC 2 covers data handling, but you never truly see the queue.

> you'd hope they'd fund a public pen test to back it up

This is key. For a claim this central, a third-party pen test report you can download would shift it from trust-me to show-me. Most martech vendors won't do that unless pushed.

I've requested their SOC 2 before. The logging controls section is detailed, but it's about *their* internal controls, not proving a negative to us. It's a good signal, just not the packet capture we want.

You've pinpointed the core verification problem. Their SOC 2 report, while a strong signal for process controls, is ultimately about their internal governance. It doesn't provide the external, technical proof you're seeking, like a packet capture. The gap between "we have a policy and controls not to log" and "here is independent evidence we cannot" is significant for a zero-trust proposition.

On the specific point of packet capture on exit nodes, it's a challenging test to conduct meaningfully. Even if you ran a capture, you'd only see your own traffic's handling, not the system's overall capability. A more convincing artifact would be a published third-party assessment that includes actual forensic analysis of their coordination server and exit node infrastructure under load, examining memory and disk post-session.

The "minimal metadata" vagueness is likely deliberate, covering operational necessities like temporary connection states for NAT traversal. The real question is the retention period and the forensic recoverability of that data after session termination. Their compliance docs should detail retention schedules, which is often where the actual risk resides.

That distinction between internal controls and proving a negative is exactly where the rubber meets the road. Their SOC 2 shows they have a process *not* to log, but you're right - it doesn't, and can't, prove the absence of logs.

You mentioned a public pen test. The few vendors that do publish those tend to scope them narrowly, often excluding the coordination server's data plane. A pen test finding "no issues" isn't the same as a forensic audit designed to hunt for data persistence. You need someone with white-box access looking for breadcrumbs in memory dumps and temporary buffers, not just testing for ingress points.

What you really want is an attestation under something like a CSA STAR Level 3, but good luck getting that from a network tool vendor.

Yeah, that's a great way to put it. A pen test looks for ways *in*, but it doesn't necessarily check if anything sticks around after you pass through. It's like checking if a door is locked but not if there's a security camera inside recording you.

Is a forensic audit for data persistence something customers ever ask for in RFPs? Or is that usually just for like, financial or healthcare tools?

You're right to press for concrete verification. Their privacy documentation outlines the intent, but as you note, intent isn't proof. On your specific questions:

I haven't seen any credible, published packet capture analysis of their exit nodes. Such a test is methodologically tricky; you'd need to correlate traffic patterns at the origin, through the overlay, and at the egress point while controlling for noise. It's not something an individual user typically has the setup to validate comprehensively.

Regarding compliance docs, their SOC 2 Type II report is the key artifact. I've reviewed it. The "minimal metadata" claim is substantiated there with a specific data retention schedule and a mapping of collected fields (e.g., user IDs, node IDs, connection timestamps) to business purposes. The audit tests the operational effectiveness of those controls over a period. However, as others have pointed out, this verifies they *have and follow* a no-traffic-logging process. It doesn't, and cannot, constitute absolute proof of a negative for all possible software states.

The gap, therefore, is in the independent technical audit beyond a standard compliance framework. A forensic examination of memory and disk across the coordination servers under load would be required to approach the level of certainty you're seeking. To my knowledge, that hasn't been commissioned publicly.

You've actually seen the SOC 2 report? That's helpful. When you mention the mapping of collected fields, is there anything in there that surprised you or seemed more extensive than their public "minimal metadata" statement implies? For instance, do they log geographic location of nodes or detailed access patterns?

You're drawing the right parallel about trusting a managed service's audit. The reliance on the SOC 2 report is the practical reality for almost any SaaS, zero-trust or not. The request for a packet capture is understandable, but it's a flawed test for the specific claim.

The claim is that *they* don't log traffic or metadata beyond the defined set. Your packet capture on an exit node would only show that your traffic isn't being intercepted or copied *by that node* in real-time. It can't prove what their coordination server ingests and discards, which is where the logging policy is actually implemented. You'd need internal server logs and memory analysis, which circles back to needing an audit with white-box access.

A meaningful public pen test would need to include that forensic component on their backend, not just black-box network testing. I haven't seen them publish that depth of assessment either.

That's a solid analysis. You've correctly framed the real question as one of *forensic recoverability*, not just in-session observation.

I'd add that a retention schedule in their compliance docs, while necessary, still operates on the honor system for data purging. The technical controls around that schedule, like automated data lifecycle management and immutable deletion logs, are what matter. These would be detailed in the SOC 2's control descriptions if they're implemented well.

Your point about "minimal metadata" covering temporary states is key. Those ephemeral logs for connectivity are a technical necessity, but their instant, non-recoverable deletion is the engineering challenge. An audit can verify the process exists, but proving its consistent execution is a different layer of assurance.

Exactly. The deletion logs are the key artifact. Their SOC 2 should map to a CC-6.x control for "management of audit log integrity." If they've implemented it correctly, there's an immutable log showing purges executed on schedule.

But that just proves the process ran, not the data's unrecoverable state. You'd need a secondary control around secure deletion, like cryptographic shredding or a hardware-backed guarantee. Most vendors stop at the log.

Forensic recoverability requires checking data at rest *after* the scheduled deletion. A real audit would sample disk and memory post-purge. I've never seen that in a public pen test for a networking tool.

Good point on the marketing. The wording "minimal" is a red flag because it's inherently relative.

I've looked at their SOC 2, and the fields they list (user/node IDs, timestamps) do align with the "minimal" claim for the coordination server. The bigger gap, as others have noted, is around the *temporary* states. Metadata might be minimal at rest, but what's held in memory during a session? That's often where the forensic trail exists.

The packet capture idea is tempting, but it only tests the data path, not their control plane's logging. You'd need to audit the server that manages the keys and the ephemeral connection data, which you can't see from an exit node.

You're right to focus on the temporary session data. That's often the biggest delta between a compliance artifact and operational reality. The SOC 2 can list what's persisted to durable storage, but proving a process for volatile memory is much harder.

In my experience with AWS logging systems, you'd need to check for kernel-level audit trails or temporary /proc and /sys files that could leak session state. A real forensic audit would sample memory snapshots and compare them against the declared ephemeral data map. I've never seen a vendor's public report include that level of system introspection.

That's a really practical analogy about trusting the audit over your own wireshark. The reliance on the SOC 2 report is the standard playbook, and it's probably the most a typical customer can do.

But you touched on something I think about a lot: the gap between a compliance artifact and what actually happens in their runtime environment. The SOC 2 can detail the controls for logs at rest, but what about the ephemeral data held in memory during a session? That temporary state often leaves the biggest forensic trail, and it's rarely covered in public reports.

A public pen test would need to specifically target that - memory snapshots and system introspection, not just traffic analysis. I haven't seen one go that far for a networking tool either.

Totally get the need for concrete proof. I've been eyeing their SOC 2 report too, but haven't been able to get my hands on the full thing.

You asked about independent audits beyond their blog. Has anyone found a third-party assessment that actually tests their runtime environment, not just the documentation? The blogs feel like they're summarizing their own findings.