The security industry has spent twenty-five years building an architecture on one load-bearing assumption: that the layer beneath you is trustworthy. Application security assumes a sound operating system. Operating system hardening assumes sound firmware. Firmware assumes sound silicon. Each layer defends against threats from above and takes the layer below on faith.
That assumption is now being questioned seriously enough that capital is moving, and the argument for questioning it has two distinct halves that are often conflated.
The two arguments, separated
The first is about AI as an attack accelerant. This one is frequently overstated in vendor marketing but has a real core. Language models have measurably lowered the cost of the labour-intensive parts of offensive work: reading unfamiliar codebases, generating plausible social engineering at scale, adapting known exploit patterns to new targets. None of this creates capabilities that did not exist. It compresses the time and skill required to apply them, which changes the population of viable attackers and the tempo defenders face.
The defensive implication is specific. Controls that depend on attacker effort being expensive — obscurity, unusual configurations, the assumption that nobody will bother reading your code carefully — degrade. Controls that depend on mathematics or hardware properties do not.
The second argument is about cryptographic durability, and it is the stronger one. Any data intercepted and stored today can be decrypted later if the underlying cryptography falls. For most traffic this is irrelevant, because the content is worthless within months. For a meaningful minority — medical records, state communications, long-lived financial instruments, industrial designs, identity credentials — the useful life of the secret exceeds the credible timeline for the cryptography protecting it. The harvest-now-decrypt-later risk is not speculative in its mechanics, only in its timing.
Both arguments converge on the same conclusion: the security properties you can rely on for the long term are the ones enforced below the software you can patch.
Edgewisely’s piece on why one European chip company raised on the argument that bolt-on security is architecturally obsolete captures the investment thesis, and the thesis is worth engaging with on its merits rather than dismissing as hardware-vendor positioning.
Why “bolt-on” is a fair description
Take a common enterprise deployment. Data is encrypted at rest and in transit. Access is controlled by identity infrastructure. Workloads run in containers on hypervisors on servers in someone else’s building. Compliance is demonstrated through audit logs and attestations.
Now enumerate what must be trusted for that to hold. The key management service and everyone with administrative access to it. The hypervisor and its patch history. The firmware on every device in the path. The supply chain that produced the boards. The provider’s own personnel controls. The correctness of the container runtime’s isolation. Each of those is a real, actively exploited category, and the defence in each case is procedural — a process, an audit, a contract — rather than physical.
Hardware-rooted approaches do not eliminate trust. They relocate it to a smaller and more inspectable set of assumptions: that a specific piece of silicon behaves as specified, and that keys generated inside it never leave. That is still trust. It is a substantially smaller surface, and critically, it is one that cannot be silently subverted by compromising an administrator’s credentials.
The uncomfortable implications for software security vendors
If a meaningful share of security enforcement moves into silicon, several established product categories become thinner.
Key management as a software product is the clearest case. Its value proposition is careful handling of material that, under a hardware-rooted model, never exists in a form software can handle. The category does not disappear — orchestration, rotation policy and lifecycle management remain real problems — but the part that justified premium pricing moves down the stack.
Runtime workload isolation is similar. Where confidential computing primitives are available and usable, software-enforced isolation becomes a fallback rather than the primary control.
Attestation and compliance tooling faces the most interesting shift. Its current job is largely to collect evidence that controls were applied. Hardware attestation replaces much of that evidence with cryptographic proof, which is both better and considerably less billable.
None of this happens quickly. Silicon cycles are five to seven years, the installed base is enormous, and heterogeneous fleets mean software fallbacks will be required for a long time. But the direction is legible, and product strategy built on the assumption that the software layer keeps its current scope is building on a shrinking foundation.
What to do in the meantime
For teams making decisions this year rather than this decade, a few things follow.
Start the cryptographic inventory now. Not a migration — an inventory. Where is cryptography used, what algorithms, what key lifetimes, what data. Most organisations cannot currently answer this, and the answer is a prerequisite for every subsequent decision. It is also useful immediately for reasons unrelated to future threats.
Classify data by secret lifetime, not by sensitivity label. The relevant question is not how bad a breach would be today, but how long the information stays damaging. A dataset that is catastrophic today and worthless in six months has a different risk profile from one that remains damaging for twenty years, and current classification schemes almost never capture this.
Treat hardware capability as a procurement requirement with a lead time. If confidential computing or hardware-rooted key handling will matter to your architecture in four years, the servers you buy in the next two cycles determine whether it is available to you. Procurement decisions made on price today constrain security architecture later, and the people making them usually are not in the security conversation.
Be sceptical of the timeline, not the direction. The direction — enforcement moving down the stack — is well supported. The timelines in vendor materials are not. Plan for the direction, buy on the evidence.
This is part of a wider pattern in which the boundaries between hardware and software keep being redrawn by capital rather than by engineering preference. Edgewisely’s survey of how the graph database category consolidated as licences tightened and acquirers moved in documents the same dynamic one layer up: categories that look stable from inside reorganise quickly when the economics underneath them shift.
One caution is worth adding for teams who find the argument persuasive. Hardware-rooted security concentrates trust as well as reducing it. A flaw in a widely deployed trusted execution environment is not patchable in the way a software flaw is, and the remediation for a broken root of trust is replacement rather than an update. Several such flaws have already been found and disclosed, and the industry’s response — mitigations with real performance costs, followed by a silicon revision years later — is an accurate preview of how the next one will go. Reducing the number of things you trust is only an improvement if the remaining thing is genuinely more reliable, and that is an empirical claim rather than an architectural one. Design with the assumption that a hardware root will eventually need to be rotated, and you will be in a better position than teams who assumed it was permanent.
The uncomfortable summary is that the security industry’s growth for two decades came from adding layers. The next phase looks like it comes from removing them — collapsing enforcement into the substrate and reducing the number of things that have to be trusted. That is better security. It is a worse business model for a lot of incumbents, which is usually a reliable signal that the shift is real.