Advanced cryptographic systems like Multi-Party Computation (MPC) promise elegant solutions to complex security problems. Cryptography is essential. Every modern system already relies on it through authentication systems, TLS in browsers, disk and database encryption, and APIs connecting services. This means every organization is, by necessity, in the key-management business, whether they recognize it or not.

However, MPC’s mathematical guarantees, like other cryptographic systems, depend entirely on operational security foundations that are often overlooked. This post uses MPC to illustrate a critical principle: cryptographic sophistication cannot compensate for operational weaknesses.

Achieving technical distribution without operational segmentation provides only the illusion of improved security.

I argue for an “outside-in” security model that prioritizes foundational defenses before investing in protection against exotic threats. The trick of course, is understanding which threats are exotic and which are impending threats. The result is a framework for rational security resource allocation that prevents expensive technology deployments from becoming elaborate security theater.

1. The Endless Security Regression

The fundamental flaw becomes apparent when you trace through an actual MPC deployment. You start with elegant mathematics that promise no single party can reconstruct the private key. Then you discover the operational reality.

The MPC shard itself needs protection, so you encrypt it with a key born and stored in a TPM. But TPMs only protect their keys from theft, not their use, and that shard key gets loaded in memory in the clear so you add a Trusted Execution Environment to protect the logic that uses the key. But TEEs have their own vulnerabilities: for example, all are vulnerable to side-channel attacks that can extract secrets from supposedly secure enclaves.

To mitigate side channels, you need dedicated hardware, but if you don’t operate them yourself, you’re now also vulnerable to cloud operators who can access hypervisor memory. So you run your code with encrypted memory and implement hardware attestation to prove the right code is running, but now those attestation keys need adequate protection, and you realize that’s outside of your control. You’ll also need x.509 certificates for network identity for the MPC nodes to communicate, which again have their own private keys, leading you back to key and certificate management again.

At every layer, the “solution” creates new secrets that need the same level of protection you originally sought to avoid. You trade software vulnerabilities for hardware vulnerabilities, single keys for multiple keys, simple operational procedures for complex distributed protocols. Each mitigation introduces new attack surfaces that are often more subtle and harder to debug and audit than the original problem.

If one person, team, or organization ultimately controls all these layers (generates the keys, manages the TPMs, configures the TEEs, handles the attestation, administers the network), then you’ve built an elaborate system that may provide no meaningful security improvement over a single well-protected key.

While not universally true, many MPC deployments are expensive ways to do what a simple, well-secured, and well-governed key can often accomplish similar outcomes with less complexity and operational overhead.

2. We Don’t Hack Crypto, We Hack How It’s Used

Government cybersecurity agencies understand this principle. The NSA explicitly states about Quantum Key Distribution: “NSA does not support the usage of QKD or QC to protect communications in National Security Systems” because “security of QKD and QC is highly implementation-dependent rather than assured by laws of physics.”

The UK’s National Cyber Security Centre takes the same position: “it does not endorse its use in government or military systems and cautions against its sole reliance on networks used by critical infrastructure.” These agencies aren’t anti-cryptography. They understand that mathematical guarantees mean nothing without operational security. As Bruce Schneier observed: ‘If you think cryptography is the answer to your problem, then you don’t understand cryptography and you don’t understand your problem.’

The overwhelming majority of security breaches don’t involve breaking cryptographic protocols or algorithms. Attackers exploit implementation bugs, misconfigured systems, stolen credentials, supply chain compromises, and human error. Advanced cryptographic systems don’t address any of these attack vectors. Instead, they add layers of complexity that introduce new opportunities for the same fundamental failure modes.

This confirms the central truth: we don’t hack cryptography; we hack the way cryptography is used. The attack surface doesn’t disappear with sophisticated protocols; it shifts to deeper, more subtle layers that are often harder to audit and secure.

3. The Resource Allocation Problem

Security budgets and time are finite. Every dollar spent hardening against more exotic threats is a dollar not spent on measures with demonstrably higher expected returns. The ROI calculation is stark: comprehensive code reviews catch implementation bugs that affect every user, penetration testing finds configuration errors that expose entire systems, and security training prevents social engineering attacks that bypass all technical controls.

Organizations consistently invert this priority structure. They deploy MPC to protect against collusion while their systems remain vulnerable to SQL injection a system the MPC implementation reads from. They implement complex attestation protocols while using default passwords. They build elaborate key distribution systems while running unpatched software.

This represents a fundamental misunderstanding of threat modeling. Academic cryptography often promotes an “inside-out” security model that begins with exotic threats: compromised hypervisors, broken cryptographic algorithms, malicious hardware manufacturers, and nation-state attacks on protocols. These are real problems, but this starting point assumes foundational security problems are already solved.

Operational security requires an “outside-in” approach. Master secure design and comprehensive code security first. Establish robust access control with mandatory multi-factor authentication. Implement secure operational procedures for deployment and monitoring. Verify the integrity of the entire supply chain and lifecycle of the services. Only after demonstrating mastery of these fundamentals does it become rational to invest in protection against sophisticated internal threats.

4. When Administrative Segmentation Actually Works

This principle of aligning cryptographic technology with operational structure is not unique to MPC. For decades, mature security programs have used dedicated hardware to achieve similar goals. A Hardware Security Module (HSM), for example, provides its greatest value not just as tamper-resistant hardware, but as a tool to enforce separation of duties.

In a robust deployment, the team managing the HSM is organizationally separate from the team developing the application that uses it. Application developers can request cryptographic operations, but they cannot access key material or manage the HSM’s lifecycle. This creates two distinct operational domains, forcing an attacker to compromise both the application and the separate security team to exfiltrate a key.

Multi-Party Computation should be viewed through the same lens. It is a powerful cryptographic tool for achieving a similar end goal, creating separate, non-colluding operational domains. The mathematical distribution of key shares is the technical mechanism, but the resulting security value is only realized when that distribution is mirrored by genuine administrative and organizational independence. Like an HSM managed by a single administrator, an MPC network controlled by a single entity becomes an exercise in costly ceremony, not a meaningful transfer of risk.

It’s important to acknowledge that the “outside-in” prioritization model must be adapted for specialized providers. For a custodian of high-value digital assets, for instance, insider collusion and key exfiltration represent the primary existential risks, justifying an intense focus on internal threats. However, this is where the conflict between security and complexity becomes most acute. Even for these organizations, each layer of cryptographic defense adds operational intricacy and new, subtle attack surfaces. This reinforces the core thesis, the goal is not merely to layer technology, but to achieve genuine, independent operational segmentation, which remains the most effective defense against those very insider threats.

A common application attempts to create segmentation for a single user by distributing key shares across their personal devices, such as a laptop and mobile phone. The stated goal is to mitigate device compromise threats. While this approach provides technical and physical separation that raises the bar for attackers, it fails to solve the underlying administrative domain problem. In this case, the domain is the single, fallible human user.

The security of the entire system still collapses to the judgment and security hygiene of one person. A sophisticated phishing campaign can compromise both devices, defeating the technical separation. This model trades a simple technical exploit for a more complex social engineering challenge, but it doesn’t achieve the resilient segmentation that comes from genuinely independent administrative control by different people or organizations.

Real value emerges when organizations delegate specific functions to genuinely independent third parties. This is where MPC’s verifiability properties become a critical enabler. Cross-organizational collaborations work when participants have different incentive structures, operate under different regulatory constraints, and maintain separate operational procedures.

The critical question isn’t “Are the keys distributed?” but “Are the operational domains truly independent?” This requires different administrative control, different legal jurisdictions, different physical infrastructure, and different threat models. Without this genuine independence, MPC can become expensive security theater.

MPC also enables unique capabilities that justify complexity when applied correctly. Beyond cryptographic key management, MPC provides genuine value for privacy-preserving collaboration across organizational boundaries. When genuinely distrustful parties need to compute insights from combined datasets, MPC offers capabilities impossible to achieve through traditional security models.

This principle of provable quorums extends to critical internal operations as well. For instance, in a software deployment system requiring M-of-N approvals, MPC can transform the process from one based on a trusted policy engine (like a source control platform) to one that is cryptographically provable, where the deployment signature itself is the non-repudiable proof that the quorum was met. Other examples where MPC shines are cross-organizational collaboration, consider multiple hospitals training medical AI models without sharing patient data, or financial institutions collaborating on fraud detection models while keeping transaction data private. These scenarios involve genuinely independent organizations with different regulatory constraints, administrative controls, business interests, and operational procedures.

In cryptographic applications, MPC is often deployed to protect keys from theft, but the real threat is typically unauthorized signing rather than key exfiltration. An attacker who can trick a system into signing a malicious transaction has achieved their goal without ever seeing the private key. This threat model actually supports our broader argument, the operational security around the signing process, authentication, authorization, and audit trails matter more than the mathematical distribution of the key material itself.

5. The Gap Between Mathematical and Operational Security

This reveals the persistent gap between theoretical and practical security. MPC provides elegant mathematical guarantees against collusion, but these guarantees assume participants have already solved the mundane security problems that cause most breaches.

Similarly, transparency systems can provide complete auditability while remaining fundamentally insecure. A transparent but insecure system allows everyone to watch the breach happen in real time. The visibility doesn’t create security.

MPC follows this pattern. Strong mathematical guarantees against collusion become meaningless if participants are vulnerable to simpler attacks. The verifiability that makes MPC compelling only matters if the systems performing computations are themselves trustworthy. Mathematical elegance doesn’t compensate for operational weaknesses.

This gap between theoretical and practical security explains why sophisticated attackers often ignore advanced cryptographic protections entirely. They find it easier to compromise endpoints, exploit implementation bugs, or target operational procedures than to break mathematical protocols.

6. Building Real Security Foundations

True security comes from systematically eliminating vulnerabilities in order of probability and impact. This requires disciplined resource allocation that resists the allure of sophisticated solutions until fundamentals are mastered.

The foundation must include comprehensive implementation security through rigorous code audits and secure development practices. Access control requires mandatory multi-factor authentication, least privilege principles, and robust identity management. Operational security demands secure deployment procedures, continuous monitoring, and effective incident response capabilities. Supply chain security requires verification of all dependencies and infrastructure components.

Organizations that build this foundation create systems so robust that only extraordinary attackers with exceptional resources pose meaningful threats. For these organizations, advanced cryptographic systems like MPC provide genuine additional value by addressing remaining threats that can’t be mitigated through conventional means.

Organizations that skip these fundamentals in favor of advanced cryptography build impressive technical complexity on unstable foundations. They solve exotic problems while remaining vulnerable to mundane attacks.

The Capstone on the Pyramid

Advanced cryptography represents some of humanity’s most remarkable intellectual achievements. MPC provides mathematically verifiable guarantees that are impossible to achieve through traditional systems. Its ability to enable privacy-preserving collaboration and eliminate single points of failure makes it invaluable for specific use cases.

However, these technologies are tools for the top of the security hierarchy. They should be the final components in mature security programs that have already eliminated implementation vulnerabilities, established robust operational procedures, and built resilience against common attack vectors.

One pragmatic consideration is that the excitement around advanced technologies like MPC can be a strategic lever for security leaders to secure budget for foundational improvements, such as cryptographic inventories or access controls, needed to realize that technology’s value. Post-quantum cryptography illustrates this perfectly: migration is the capstone, but preparation (creating inventories, achieving operational agility) is foundational work that must start immediately. Yet, for most organizations, an outside-in approach delivers larger security improvements per dollar invested.

The goal isn’t to avoid advanced cryptography but to apply it strategically. Organizations that understand the primacy of operational security can deploy MPC effectively as a capstone technology. Those who use it as a substitute for security fundamentals will find themselves with expensive, complex systems that provide little meaningful improvement to their actual security posture.

Defense first, technology second. This principle transforms security into a systematic process of eliminating vulnerabilities, ensuring finite resources target critical threats for maximum impact.

I advised Let’s Encrypt from its early days, watching it transform the security foundation of the web. Most think it won by offering free certificates. That’s dead wrong.

Existing CAs had already enabled free certificates years earlier. GlobalSign’s CloudSSL API, launched in 2011, (in full disclosure, I was their CTO), provided the automation that allowed Cloudflare to offer free SSL to end users; other CAs offered free short-lived certificates as part of forever trials as well. By 2015, you could buy DV certificates for $3-5 from certificate resellers, it was clear people were willing to pay for support which is largely what these resellers offered. The real story is about organizational constraints and misaligned incentives.

Conway’s Law Explains Everything

Traditional certificate authorities were trapped by their own organizational structure. Their business model incentivized vendor lock-in rather than ecosystem expansion and optimization. Sales teams wanted products’ proprietary APIs to make it harder for customers to switch, and were riding the wave of internet expansion. Compliance teams’ jobs depended on defending existing processes. Engineering teams were comfortable punting all compliance work to the “compliance” department. Support teams were positioned as competitive differentiators and used to entrench customers. Their goal was maximizing revenue, defending their jobs, and maintaining the status quo, not getting the web to 100% HTTPS.

Let’s Encrypt had completely different incentives and could optimize solving the larger problems without these organizational constraints. But LE’s success went beyond solving their own problems. They systematically identified every pain point in the way of getting to 100% HTTPS and built solutions that worked for everyone.

What LE Could Do That Traditional CAs Couldn’t

True standardization. Before ACME (the protocol that automates certificate requests), every major CA had incompatible automation systems. Comodo, DigiCert, GlobalSign and others each had proprietary approaches that required custom integration and as a result, had inherent switching costs; they saw no incentive to work together to standardize as a result. LE led the creation of ACME as an open standard that made switching CAs as simple as changing a configuration setting.

This enabled applications like Caddy and Google Cloud Load Balancer to handle certificates automatically for their customers without vendor-specific code. Once cloud platforms could flip switches to HTTPS-by-default, network effects became unstoppable.

Ecosystem-wide solutions. When LE felt coordination pain from renewal spikes and incident-related revocations, they created ACME Renewal Information (ARI, a protocol extension that helps coordinate renewal timing) so all CAs could prevent renewal storms. Traditional CAs couldn’t build these solutions because their org charts prevented optimizing for competitors’ success and instead focused on riding the internet expansion.

Engineering-driven compliance. Instead of compliance teams reviewing certificates after issuance, LE built policy compliance directly into certificate generation pipelines. Violations became orders of magnitude harder rather than detectable. Traditional CAs couldn’t eliminate their compliance departments because those jobs justified organizational overhead.

The Market Found Natural Segments

Mozilla telemetry reveals exactly what happened. Let’s Encrypt dominates issuance at 46.1% of certificates but ranks third in Firefox usage. LE democratized HTTPS for the long tail: domain parking networks, no-code builders, shared hosting platforms serving millions of low-traffic sites.

Meanwhile, high-traffic sites gravitated toward CAs like Google Trust Services (in full disclosure, I was responsible for creation of this service) that lead usage, as its used by large sites that value high availability and performance, leading to more relying party reliance despite lower issuance volumes, or established players like DigiCert and Sectigo that focus on supporting large enterprise customers. These sites need commercial support and accountability when things go wrong. The market is segmented around operational needs: the long tail valued automation over accountability, while major platforms needed enterprise support and someone to support them when something goes wrong.

Once long-tail providers flipped to HTTPS-by-default, encrypted pages became the norm. Google’s Transparency Report shows 99% of Chrome page-loads now occur over HTTPS, a transformation that began when Let’s Encrypt launched in April 2016.

The Industry Finally Admitted LE Was Right

Here’s the ultimate vindication: in 2025, the CA/Browser Forum mandated 47-day maximum certificate validity by 2029, with Chrome requiring automation from every public CA. Let’s Encrypt didn’t follow industry trends. The industry now follows Let’s Encrypt.

What seemed like LE’s “unusual” 90-day lifespans in 2016 became conservative by 2025. The mandate’s technical reasoning mirrors what LE pioneered: short-lived certificates reduce dependence on revocation checking, reduce key compromise windows, and force automated resilient infrastructure.

Leading organizations moved even further ahead. Netflix runs 30-day certificates in production, Google issues 7-day certificates for infrastructure, and Let’s Encrypt will introduce 6-day certificates by end of 2025. The mandates aren’t pushing innovation forward; they’re codifying where leaders already operate.

Why This Matters Beyond Certificates

Let’s Encrypt proved that critical internet infrastructure could be reimagined from first principles rather than optimized around legacy organizational constraints and practices. But the implications go deeper than certificate automation.

Traditional CAs were fundamentally vetting authorities with deep expertise in legal requirements for vetting people and businesses worldwide. They should have owned the remote identity verification market that exploded with digital transformation. Instead, they remained myopically focused on public trust-based certificate products while companies like Jumio and Onfido captured those opportunities. At the same time, they missed the massive expansion of machine and workload identity because they were ignoring private PKI use cases. They weren’t just leaving money on the table; they were failing to build a resilient business and neglecting the foundation for the trust infrastructure they supposedly managed.

The same organizational constraints that prevented CAs from building ACME also blinded them to adjacent markets that were natural extensions of their core competencies. They were too focused on maintaining certificate revenue streams and too constrained by existing structures to recognize how the world was shifting from hosting providers to cloud to SaaS.

ACME became the standard not because it was technically superior to existing APIs, though it was, but because it was designed for portability rather than lock-in. ARI emerged because LE experienced ecosystem pain and could fix it without navigating corporate bureaucracy or competitive concerns.

The complexity and friction we’d accepted for decades weren’t inherent to certificate management. It was the byproduct of organizational structures optimizing for vendor revenue rather than user adoption.

Today’s 47-day mandate represents more than policy evolution. It’s the industry formally acknowledging that Let’s Encrypt defined the correct approach for internet trust infrastructure. Conway’s Law isn’t destiny, but escaping it requires the courage to rebuild systems around user needs rather than organizational convenience.