A Manifesto for Post-Software Security

The Core Assumption: All Software Is Compromised

Modern security strategy must start from one foundational assumption: all software is permanently and totally compromised. This is not pessimism but a rational conclusion from computing reality. The attack surface of a modern system is not merely large. It is functionally infinite. An operating system, a web browser, their device drivers, and the application frameworks binding them together create a codebase so complex that comprehensive security analysis is mathematically impossible. Within this web of interactions, exploitable vulnerabilities are guaranteed, not possible. Sophisticated adversaries can discover and weaponize these flaws faster than any defensive cycle can patch them. Operating on the assumption that any networked device is clean or trustworthy means operating from fatal ignorance. The only tenable posture is treating every digital environment as inherently hostile.

Why Software Cannot Protect Itself

Security solutions that are themselves software are built on a fundamentally flawed premise. They must protect secrets while executing on operating systems that should be assumed compromised. A software password manager, for example, is a user-space application requesting the master key to a user’s entire digital identity from an environment potentially controlled by an adversary. This creates a paradox where the guardian must ask the prisoner for the keys to the prison.

The vulnerability is systemic and appears at every interaction point. The keystrokes of a master password are handled by the compromised input subsystem. The decrypted credentials reside in memory accessible to the host. Any interaction with operating system APIs like the clipboard becomes a potential interception point. An attacker controlling the endpoint does not need to defeat the application’s cryptography. They only need to wait for the user to voluntarily introduce the secret into the hostile environment through normal operation.

This failure is not probabilistic. It is a deterministic outcome of the architecture. Each use of the system exposes the core secret. A single instance of this exposure results in total security collapse. Any security model that relies on presenting secrets to an untrusted software environment is architecturally doomed.

The Only Two Valid Approaches: Immunity and Isolation

Given the inherent hostility of the software layer, only two architectural approaches provide genuine protection for secrets. Both share a common principle: they remove sensitive data from the domain of untrusted software. The first approach achieves this through physical, analog means, creating absolute immunity from digital attack. The second achieves it through dedicated hardware, creating absolute isolation within a secure digital enclave. These are not variations on a theme but the only two valid solutions in a post-trust software world. Any strategy relying on software-based cryptography running on a general-purpose operating system exists in perpetual compromise and is inadequate for securing high-value assets.

Physical Immunity: Removing Secrets from the Digital Domain

The principle of physical immunity is achieved by storing secrets in plaintext on a physical medium like paper, secured within a physically controlled location like a safe. This method removes the secret entirely from the digital domain. It is invulnerable to zero-day exploits, malware, remote code execution, or network-based attacks. Its security is not a function of code integrity or patch management but of physical access control.

An adversary must gain physical proximity and defeat physical barriers, which presents an entirely different and often more detectable threat model. By creating a literal and complete air gap, physical storage renders the entire category of digital attack irrelevant. This establishes a baseline of security that no purely software-based architecture can replicate.

Physical storage has obvious limitations for frequently accessed credentials. But for high-value secrets like recovery keys, root passwords, or cryptographic seeds, the inconvenience of physical access is a feature, not a bug. The friction forces deliberate action and makes casual compromise impossible. For secrets that must remain accessible in digital form, isolation becomes the only viable path.

Hardware Isolation: Dedicated Cryptographic Enclaves

For secrets that must remain in usable digital form, isolation is the only viable path. This is accomplished through dedicated cryptographic hardware like Hardware Security Modules (HSMs) or Trusted Platform Modules (TPMs). These devices are not hardened software programs. They are specialized cryptoprocessors designed from the ground up to isolate and protect cryptographic material.

Their architecture enforces a strict and unbreakable boundary: cryptographic keys are generated inside the HSM and can never be extracted. The compromised host system does not handle the keys directly. Instead, it sends authenticated, operation-specific requests to the HSM, such as:

sign this data

or

decrypt this payload

The HSM performs the operation within its secure perimeter and returns only the result. The keys themselves are permanently sequestered. This architectural separation negates the primary attack vector against software solutions. Even with full kernel-level control of the host, an adversary cannot exfiltrate the keys because the keys do not exist in any addressable space the compromised system can reach.

This is fundamentally different from software encryption. Software encryption stores keys in memory that the operating system manages. An attacker with system access can dump that memory. Hardware isolation makes the keys physically inaccessible to the host. The cryptographic operations happen inside a separate chip with its own processor, memory, and security controls. The host never sees the key material.

Engineering Against Physical Attacks

Hardware-based security is designed to counter threats that operate at the physical level, a domain where software has no agency. Properly engineered HSMs incorporate defenses against sophisticated side-channel attacks, where adversaries attempt to infer secrets by observing the physical characteristics of the device.

These defenses include constant-time implementations to neutralize timing attacks. The device performs operations in fixed time regardless of the data, preventing adversaries from inferring key bits from execution time variations. Circuitry randomizes power consumption against power analysis attacks. These attacks try to correlate power draw patterns with cryptographic operations. Fault detection systems prevent attacks that manipulate voltage or clock frequency to induce errors that leak information.

The final line of defense is physical tamper resistance. Sensors embedded within the HSM detect attempts at physical intrusion like chassis penetration, abnormal voltage, or temperature changes. Upon detecting tampering, the device executes an immediate zeroization routine. This cryptographically erases all secrets and renders the device permanently inoperable. This self-destruct mechanism ensures secrets are destroyed before a physical attack can succeed. This engineering creates a system where secrets remain protected even from adversaries with physical possession and advanced laboratory capabilities.

Modern HSMs go further with secure boot processes, signed firmware updates, and audit logging of all cryptographic operations. These layers create defense in depth. Compromising an HSM requires defeating multiple independent security mechanisms, each designed by specialists in hardware security. This is fundamentally more difficult than exploiting a software vulnerability in a general-purpose operating system.

Why Software Solutions Keep Failing

The software security industry continues producing products that cannot work. Password managers, encrypted file systems, and software-based encryption tools all share the same fatal flaw. They run in user space on compromised operating systems. They must ask that compromised system to handle their most sensitive operations.

Consider the typical password manager workflow. The user types a master password. The operating system’s input subsystem captures those keystrokes. The password manager application receives them through OS APIs. The application uses them to decrypt a password database. The decrypted passwords sit in application memory managed by the operating system. When the user copies a password, it goes through the OS clipboard. When the user types it into a browser, it goes through the same compromised input subsystem.

At every single step, the compromised operating system has access to the secret. The password manager’s encryption is irrelevant. The attacker doesn’t need to break AES-256. They just need to read memory or intercept API calls. This is not a vulnerability in the password manager. It is the inevitable consequence of trying to protect secrets in software.

The same pattern repeats across all software security solutions. Full disk encryption protects data at rest but not data in use. Once the system boots and the user logs in, all encrypted data must be decrypted into memory for use. That memory is controlled by the potentially compromised operating system. Software firewalls run as processes that a compromised kernel can modify. Antivirus software can be disabled by malware with sufficient privileges. Every software security tool is ultimately just more software running on the same untrustworthy foundation.

The Economic Reality

The software security industry has strong financial incentives to ignore these fundamental problems. Selling software is more profitable than selling hardware. Software scales infinitely with near-zero marginal cost. Hardware requires manufacturing, inventory, and logistics. Software can be updated remotely. Hardware requires physical deployment.

This economic reality explains why the market is flooded with software security products despite their architectural impossibility of success. The industry has optimized for what is profitable to sell rather than what actually works. The result is a massive ecosystem of security theater: products that create the appearance of protection while providing none of the substance.

Users buy these products because they don’t understand the fundamental architectural problems. The marketing focuses on features, encryption algorithms, and certifications rather than the core question: can this product protect secrets from a compromised operating system? The answer is always no, but that answer doesn’t sell software.

Practical Implementation

Understanding that software security is broken does not mean abandoning all software tools. It means using them appropriately within their limitations. Software tools can provide defense in depth against unsophisticated attacks. They cannot provide protection against determined adversaries with system-level access.

For truly sensitive secrets, the only valid approaches are physical immunity or hardware isolation. Critical infrastructure should use HSMs for cryptographic operations. Root keys should be stored in TPMs. Recovery codes should be written on paper and locked in safes. These are not paranoid measures. They are rational responses to the reality of software compromise.

The practical challenge is that hardware security modules are expensive and complex to deploy. Enterprise-grade HSMs cost thousands to tens of thousands of dollars. They require specialized knowledge to configure. This creates a gap where organizations know software solutions are inadequate but lack resources or expertise for hardware alternatives.

This gap is closing. Modern processors include TPMs as standard features. Cloud providers offer HSM services that abstract away deployment complexity. Hardware security keys for multi-factor authentication have become affordable consumer products. The technology for hardware-based security is increasingly accessible. What remains lacking is widespread understanding of why it is necessary.

The Path Forward

The era of trusting software to protect its own secrets is over. The complexity of modern codebases and the capabilities of adversaries have made the architectural flaws of software-only security untenable. The only rational path forward is fundamental migration away from software-dependent protection models.

Security must be built on one of two principles: absolute physical immunity, where secrets are removed from the digital world entirely, or absolute hardware isolation, where secrets are used within a dedicated, tamper-resistant digital enclave. Any approach that falls between these paradigms, relying on the integrity of a general-purpose operating system, is fundamentally broken.

The choice is no longer between different software tools but between the only two architectures that can withstand a hostile software environment. There is no third option. Organizations and individuals must accept this reality and plan accordingly. The question is not whether software security is adequate but how quickly we can transition to architectures that actually work.