Resources

Zero-Knowledge Architecture Is Not Optional: What Recent Federal Breach Notifications Mean for Enterprise Infrastructure Design

In the first quarter of 2026, the U.S. Department of Health and Human Services Office for Civil Rights published breach notification data showing a 34% year-over-year increase in reported healthcare data breaches affecting more than 500 individuals. The common thread across the majority of these incidents was not sophisticated nation-state intrusions but a simpler, more damning pattern: service providers had access to customer data they had no operational need to access.

This is not a new observation. The security community has understood for decades that superfluous access is the root of most preventable breaches. What has changed is the regulatory and insurance environment. Cyber insurers now routinely require evidence of data minimization and access control architectures as a condition of coverage. The SEC's cybersecurity disclosure rules, effective since December 2023, have made breach notification a materiality question with board-level consequences.

A zero-knowledge architecture addresses this at the structural level rather than the policy level. When a service provider has no technical ability to access customer data — when the encryption is performed client-side and the keys never leave the customer's environment — the provider simply cannot be the vector for a data breach of customer content. This is not a feature. It is the absence of a vulnerability.

The distinction that matters

Enterprise IT organizations frequently conflate "encryption at rest" with "zero-knowledge." They are not the same thing. Encryption at rest — where the service provider encrypts data using keys it controls — protects against physical theft of storage media. It does not protect against a compromised administrator account, a rogue employee, a subpoena directed at the provider, or a vulnerability in the provider's application layer. In all of these scenarios, the provider can still access the plaintext.

Zero-knowledge means the provider never has the keys. The encryption happens before the data leaves the client. The provider stores ciphertext exclusively. This is a fundamentally different security model with fundamentally different legal and operational implications — including implications for how the provider responds to legal process, as we have discussed in previous articles and in our published compliance documentation.

Practical considerations for evaluation

When evaluating zero-knowledge architectures, there are a few diagnostic questions that cut through marketing claims. First: during the key ceremony, does any key material ever exist in the provider's environment, even transiently? Second: if the provider receives a valid subpoena for your data, what exactly can they produce? If the answer is anything other than "ciphertext," the architecture is not zero-knowledge. Third: can the provider's engineering staff, acting with full administrative privileges, read your data? If yes, you have encryption at rest, not zero-knowledge.

These are uncomfortable questions for most providers. They should be. The answers expose assumptions that most organizations have never explicitly examined. At CYFR, we publish the answers in our security architecture documentation and we encourage prospective customers to test them through independent technical assessment.

Tags: zero-knowledge, encryption, compliance, breach prevention, security architecture

Per-Session Key Negotiation: How We Built Access Revocation That Actually Works

Access revocation is one of those security primitives that sounds simple and turns out to be extraordinarily difficult to implement correctly. The naive approach — remove a user's account and assume all their access tokens are invalidated — fails in distributed systems for reasons that are well-documented but still regularly encountered in production incidents. Token caches, load balancer session stickiness, and the fundamental eventual consistency of revocation lists all conspire to create windows during which a revoked user can still access data.

Our approach at CYFR addresses this at the cryptographic layer rather than the application layer. Every media access event — every file download, every stream initiation, every thumbnail fetch — negotiates a unique, ephemeral session key. The URL that the client receives embeds a non-reversible hash derived from the user's permanent access identifier, the content reference, and a timestamp. No two access events produce the same URL. No URL can be used to derive the user's identity without the server-side mapping table. And critically, revocation is not a matter of adding an entry to a list and waiting for propagation. It is a matter of the key server simply refusing to negotiate new session keys for a revoked user or a revoked content reference.

The system is not novel — variants of this approach appear in TLS session resumption, Kerberos ticket-granting, and OAuth refresh token rotation — but applying it uniformly to every data access event at the application layer produces a property that is rare in practice: guaranteed revocation within sixty seconds of issuance, globally, with no cache invalidation races.

A side effect: audit precision

Because every access event produces a unique cryptographic artifact, the audit trail is correspondingly precise. An organization can determine not merely that a particular user accessed a particular file at a particular time, but that a specific access URL — leaked, shared, or otherwise exposed — was the vector. This has turned out to be operationally valuable for our enterprise customers in ways we did not fully anticipate when designing the system. Copyright enforcement, internal leak investigation, and compliance reporting all benefit from URL-granularity audit records that do not require the provider to inspect content.

Tags: key management, access control, cryptography, per-session keys, audit logging

Choosing Between Storage and Backup: They Solve Different Problems

A surprising number of enterprise RFPs conflate cloud storage and cloud backup into a single requirement. The conflation is understandable — both involve putting data in the cloud — but it leads to architectures that fail under the very conditions they were designed to survive.

Cloud storage (CYFR Vault) is a primary data repository. It is the canonical location for files that users actively access, modify, and share. Its design priorities are availability, low-latency access, and collaborative features — shared folders, granular permissions, version history. Data in a storage system is live. It changes.

Cloud backup (CYFR Backup) is an insurance policy. Its design priorities are durability, immutability, and recoverability. Data in a backup system should not change — it should be a point-in-time snapshot preserved against a future restoration event. A good backup system is boring. It sits quietly, verifies integrity on a schedule, and is ready for the one day when everything else has failed.

The failure mode of conflating the two is well-known but persistent: an organization stores the only copy of critical data in a storage system, assumes the storage system "backs things up," and discovers during a ransomware incident that the storage system's replication propagated the encrypted files to every replica. The backup — the immutable, air-gapped, point-in-time copy — was never created because the organization believed storage and backup were the same thing.

Our recommendation to enterprise customers is straightforward: use CYFR Vault for live data that teams actively work with. Configure CYFR Backup for automated, encrypted, immutable snapshots on a retention schedule that matches your recovery point objective. They are designed to complement each other, not substitute for each other. The encryption is the same AES-256-GCM. The zero-knowledge architecture is the same. The purposes are different.

Tags: storage, backup, disaster recovery, architecture, best practices

What SOC 2 Actually Tests (and What It Doesn't): A Guide for Technical Evaluators

SOC 2 has become the default compliance certification for B2B SaaS companies, but its meaning is widely misunderstood by the technical staff who are frequently asked to evaluate vendors based on it. This article provides a technical perspective on what SOC 2 does and does not attest to, with an emphasis on the implications for zero-knowledge architectures.

SOC 2 is an attestation, not a certification. An independent CPA firm examines a service organization's controls relevant to one or more Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — and issues an opinion on whether those controls are suitably designed and operating effectively. The key phrase is "controls relevant to." The organization defines which criteria are in scope. A SOC 2 Type II report attests that the controls the organization claims to have in place were actually operating over a defined period (typically six to twelve months).

What SOC 2 does not do: it does not certify that a product is secure. It does not involve penetration testing (that is a separate activity, which CYFR conducts quarterly). It does not audit the product's cryptographic implementation. It does not evaluate whether a zero-knowledge architecture functions as claimed. It audits whether the organization has documented processes, follows them, and can produce evidence that it follows them.

For technical evaluators, the practical implication is that SOC 2 is a necessary but insufficient condition for trust in a zero-knowledge provider. A SOC 2 report tells you that the provider has mature operational processes. It does not tell you whether the provider can actually access your data. For that, you need architectural documentation, independent technical assessment, and — ideally — a contractual representation backed by audit rights.

What to look for in a SOC 2 report for a zero-knowledge provider

When reviewing a SOC 2 report for a provider claiming zero-knowledge architecture, pay particular attention to: (1) the description of the system — does it clearly state that the provider does not possess customer encryption keys and cannot access plaintext customer data? (2) the control activities related to key management — are there controls that specifically test that no key material exists in the provider's environment? (3) the complementary user entity controls — does the report place explicit responsibilities on the customer for key management, encryption, and access control? If the report is ambiguous on any of these points, the zero-knowledge claim warrants further investigation.

At CYFR, we make our SOC 2 Type II report available to prospective customers under NDA. The report explicitly describes our zero-knowledge architecture, the absence of key material in our infrastructure, and the complementary controls we expect customers to implement. We believe transparency on these points serves both security and the sales process — it eliminates ambiguity about what we can and cannot do with customer data, which is, after all, the whole point of the architecture.

Tags: SOC 2, compliance, auditing, zero-knowledge, vendor evaluation