Has anyone done a proper comparison of state encryption at rest across tools?

You're right that this detail is often overlooked. I did a similar comparison last quarter when evaluating a shift in our primary IaC platform. The key management piece is where the real divergence happens.

Terraform Cloud's provider-managed keys were a dealbreaker for our finance team due to specific regulatory requirements. Pulumi's model using the cloud provider's KMS meant the key management and audit trail were already integrated into our existing cloud governance. OpenTofu was essentially a wildcard, as its security posture is entirely a function of your chosen backend's capabilities, which makes a true apples-to-apples comparison impossible.

The bigger issue I found isn't just the encryption standard, but key rotation policies and auditability. Can you prove who accessed the state and when? Terraform Cloud provides that log, but only if you're on their Business tier. With Pulumi and a cloud backend, those logs are part of your cloud provider's native services, which may already be covered under your current compliance framework.

That's a decent start, but you're still buying the vendor framing. The real question isn't about logs being "part of your cloud provider's native services," it's about who can *see* those logs and who owns the policy.

You mentioned Pulumi's model using the cloud KMS. Sure, you get your cloud provider's audit trail. But you're now tying your IaC vendor's access patterns to your cloud IAM. Does Pulumi's backend service use a cross-account IAM role? A service principal? That's another layer of vendor-specific trust you have to audit, regardless of the pretty compliance checkbox.

And let's be honest, if your finance team had a problem with HashiCorp holding the keys, they should be equally skeptical of Pulumi's access to the KMS via *their* backend. You've just swapped one opaque vendor control plane for another.

You make a good point about vendor access patterns. It shifts the trust but doesn't eliminate it.

For someone new to this, how do you even start auditing that? Do you ask the vendor for their backend's IAM policy, or is that considered internal?

I actually built a spreadsheet for this exact comparison last year! It's great you're looking beyond the basic "AES-256" checkbox.

A few specifics that stood out:
* Terraform Cloud's provider-managed keys are indeed the default, but their Business tier does support bringing your own encryption key via the AWS KMS integration. That's a cost and tier detail often missed.
* Pulumi's default is cloud KMS, but their "self-managed backend" option lets you run the control plane yourself, so you handle all encryption (like using a self-hosted Vault). That blurs the line between "cloud" and "self-hosted."
* The biggest gap in most comparisons is the encryption of the state *in transit* between the CLI and the backend. Some tools use TLS with pinned certificates, some don't. That's as important as at-rest.

For secrets within state, everyone basically says "don't put them there." The difference is in how they help you avoid it. Terraform has the `sensitive` flag (but it's just a UI marker, the value is still in state). Pulumi pushes you toward their secrets manager, which is an extra service to consider.

Happy to share that spreadsheet if it's helpful. Did you come across any specific compliance requirement (like FedRAMP or SOC2) that's driving your review? That often dictates the "right" answer.

Great points, especially about the in-transit encryption being a common blind spot. I've seen teams focus so hard on AES-256 at rest that they miss a tool using an outdated TLS config or not validating certificates properly for state operations.

Your note on the `sensitive` flag is spot on. It's a UX feature, not a security one. The real value is in preventing accidental log output, but it does nothing for the state file itself. For a true secrets workflow, you're forced into external systems like Vault or the cloud's secret manager, which makes the state encryption almost a secondary concern.

I'd be really interested to see that spreadsheet, especially if you captured the TLS/transit details. Did you happen to include Atlantis or other CI/CD-centric tools in your comparison? Their model adds another layer, since state often passes through the CI runner's memory.

You're absolutely right that the feature comparisons often skip over these details. I've found the key management piece is what really forces a decision.

One thing I'd add: even if a tool offers a "self-hosted" option, you need to check if that just means you run their backend container, or if you truly own the full data plane. Some vendors call it self-hosted but still phone home for metadata, which can leak info about your state operations.

And totally agree on the cloud vs self-hosted differences. For Terraform Cloud, using their "standard" tier means you're accepting their key lifecycle management, full stop. But if you self-host the Terraform Enterprise installer, you're suddenly responsible for the entire HSM and PKI setup - a massive ops lift that doesn't get mentioned enough in the docs.

You're right to push beyond the feature sheet on this. That "critical security consideration" feeling is spot on, and it's usually felt during an audit or right after a breach.

One angle I haven't seen mentioned yet is the operational shock of *changing* your mind later. Say you start on Terraform Cloud's standard tier for speed. You grow, your compliance team demands BYOK, so you upgrade to Business and integrate KMS. That's a clean, supported path. Now imagine the same demand hitting a self-hosted OpenTofu setup using a local S3 backend. Suddenly you're not just configuring a tool, you're designing a key rotation schedule and hardening access to an entire storage account. The "configurability" of a tool becomes a direct measure of your in-house ops burden.

The secret handling difference is mostly theater, too. Marking a variable as `sensitive` might keep it out of the console output, but it's still plaintext in the state file. The real solution - external secrets management - ironically makes the state file's own encryption less relevant, because the juicy bits aren't even in there anymore. The comparison then shifts to "how well does this tool integrate with Vault or AWS Secrets Manager?", which is a totally different spreadsheet.

I'd love to see someone's comparison include the rollback procedures. If a key is compromised or rotated, can you decrypt all historical state files to re-encrypt them, or are you just protecting new writes? That's a brutal question to answer at 2 a.m.