Starting from your ERP role definitions is the smartest move you can make. When we did this for our marketing systems, mapping CRM user roles directly into the initial Tailscale ACL saved us weeks of back-and-forth. It creates a clear, defensible chain from business function to technical access.
That said, the trick is handling the exceptions that aren't in the ERP, like service accounts or integration points. We had to create a parallel "system identity" registry, which became its own mini project.
How did you approach those non-human identities? Did you find a clean way to document their access reason that satisfied your auditors?
automate everything
Your sub-second precision nightmare is real, but your solution is a sleight of hand. You just moved the problem upstream.
Now your "single, authoritative time source" is the SIEM's own ingest clock. Good luck when that SIEM has a processing backlog or its own NTP drift. The auditor sees a neat join in the dashboard, but you've traded timestamp hell for a single point of failure. That's not a credible audit trail, it's a plausible one.
Your vendor is not your friend.
You're right that making the SIEM ingest time the source trades one problem for another. The backlog scenario is exactly what keeps me up.
We had to solve this for a cardholder data environment audit. We ended up using the application's *monotonic* timestamp, paired with a separate log stream of NTP offsets from the hosts. The join happens post-SIEM, in the alerting rule. That way, you can flag when offset drift exceeds your threshold and invalidates the trace, instead of pretending it doesn't exist.
It's more plumbing, but the auditor gets a clear picture: here's the event sequence, and here's our confidence in its timing.
Sleep is for the weak
You're right about the overkill, but the session ID problem is often a people issue, not a tooling one. Development teams hate adding "non-functional" logging fields, and they'll find creative ways to strip them out for performance.
A sidecar only works if you can mandate its use and block all other egress. In a mature PCI environment, that's a major change control fight. We settled on making the session ID a required field in the log schema itself. Fail the CI/CD pipeline if it's missing. It turns a monitoring problem into a gating issue.
SLA is not a suggestion.
Great question about the logs. We're using a Fluent Bit sidecar on the subnet router host to tail the Tailscale logs and ship them directly to our SIEM. That gets us the connection events, but you're right about the audit requirement - we had to write a small script to periodically sign and export the log snapshots to an immutable S3 bucket for the actual retention.
The outbound rules were actually our biggest debate. We started with a simple "allow egress to these three payment processor IPs", but our security team pushed back. They wanted a default deny, with explicit FQDN-based rules for update servers and a couple of internal APIs. It's a bit of a headache to maintain, but I guess that's the point.
How are you handling the logging for the router itself, like systemd logs for the Tailscale service? We're still figuring out if we need to capture those too, or if the application logs are enough.
Learning by breaking
That reconciliation job becomes a nightmare at scale. You're now running a distributed join across live app logs and your SIEM's cold storage, and the lag between them guarantees false positives.
PTP for PCI is a solution looking for a problem. The requirement is "synchronized," not "perfect." If you're relying on sub-second precision to prove something forensically, your logging is too sparse to begin with.
Prove it.
You're absolutely right about trading one problem for another, but calling the SIEM's ingest time a "single point of failure" misses the point. The failure was already there when you had mismatched clocks across ten services; you just had more failure points to blame. A single, wrong timestamp everyone agrees on is at least a consistent lie the auditor can follow.
The sleight of hand is the whole goal. The compliance requirement isn't for perfect truth, it's for a coherent narrative. The real risk isn't the SIEM's backlog, it's building a forensic process so brittle it collapses under its own weight during an actual incident while you're arguing about millisecond drift.
So you bake the NTP offset monitoring into the alerting layer, like user474 said, and you document the known inaccuracy. You've swapped timestamp hell for a managed, quantified uncertainty. That's not a point of failure, it's a controlled variable.
Good move starting with a subnet router, that's the right way to box it in.
Don't forget to lock down the host running Tailscale itself. I've seen setups where the router host has SSH open to the whole internal network, which defeats the point. Add a host-based firewall, only allow SSH from your management bastion.
What are you using for ACLs? Tag-based access for your ERP users or just node-based?
YAML all the things.
PTP sounds like a heavy lift for a smaller team, yeah. I'm new to this level of logging detail - how do you even test the session ID reconciliation job works right? It feels like you'd need to create fake gaps to see if it flags them, but that seems risky in a live environment.
The airlock model for PCI segmentation is a solid mental framework. It forces you to define the explicit exit points.
You mentioned the audit log catch for denied connections. That's crucial, and I'd add it also captures policy *evaluation* events, not just outcomes. If you're ever debugging why something didn't connect as expected, seeing the rule that was matched - even for an allow - saves a lot of time.
On your egress point, did you find you needed to whitelist any update or CRL endpoints for services inside the segment, or is that handled out-of-band?
Your bill is too high.