Introduction
For most of enterprise IT history, buying hardware and buying security were two different conversations, handled by two different teams, on two different timelines. Procurement negotiated price, warranty, and delivery; security got involved once the equipment was already on the network, if it got involved at all. That division of labour made sense when a server or a PC was a relatively closed box. It no longer does. Attacks have moved down the stack, below the operating system and into firmware, chipsets, and the physical supply chain itself, which means the security posture of a device is now baked in — or left out — well before a buyer ever signs a purchase order. Intel notes that hardware-based security capabilities are physically built in at the silicon level, a fundamentally different proposition than software layered on top after the fact, and one that can no longer be treated as an optional upsell in a hardware deal.
The central argument here is straightforward: cybersecurity has to become an explicit, negotiated line item in every hardware purchase — evaluated alongside price, performance, and support — rather than a problem IT inherits once the boxes arrive. The businesses that keep treating hardware and security as separate purchasing decisions are, in effect, buying risk at a discount and paying for it later, usually at a much higher price.
The Problem: Hardware Has Been the Blind Spot in Security Spending
The case for change starts with a simple, uncomfortable fact: software-based defenses were never designed to protect the layers beneath them, and attackers know it.
Attacks have moved below the OS, where most security investment doesn’t reach. Intel explains that traditional software-based protections are installed on top of hardware, leaving everything below the operating system vulnerable to an emerging class of attacks — most notably in device firmware, which runs at start-up before the OS loads and, by default, was never built with integrity checks in mind. An attacker who compromises that code gets a payload the OS will trust implicitly, because the entire chain of trust assumes the firmware was clean to begin with. This is precisely the gap that a purely software-focused security budget cannot close.
The financial and reputational stakes are not hypothetical. Analog Devices’ security white paper points to a 2016 internet outage that took down Amazon, Twitter, Netflix, and PayPal, caused by CCTV cameras and DVRs compromised by the Mirai botnet — a striking illustration of how “innocuous” connected hardware can become critical infrastructure risk. The same paper cites a Juniper Research estimate that data breaches tied to traditional computing devices could push the cost of cybercrime to $2.1 trillion by 2019, and notes that Forrester identified fleet management in transportation, security and surveillance in government, inventory management in retail, and industrial asset management in manufacturing as the sectors most exposed to a large-scale IoT breach, driven largely by rapid, security-light adoption of connected devices.
Even the most regulated industries aren’t immune. Financial services is subject to some of the strictest security standards in existence, yet a 2016 SecurityScorecard analysis of more than 7,000 financial institutions found that 75% of the top 20 U.S. commercial banks had been infected by malware, nearly one in five financial institutions relied on an email provider with severe security vulnerabilities, and 95% of top U.S. commercial banks received a network security grade of C or below. Tellingly, the same source points out that PCI DSS — the standard most retailers and banks lean on — is itself software-based, even though hardware-based controls are the more robust approach for point-of-sale transactions. Compliance, in other words, is not the same thing as security, and a hardware deal that satisfies a checklist can still leave the buyer exposed.
The vendor and supply chain, not just the deployed device, is part of the risk. ManageEngine notes that hardware risk begins at the production phase, and that some local manufacturers of smart devices supply outdated firmware riddled with bugs and security flaws, while unencrypted devices can simply be stolen and have their data extracted, and unsecured local access leaves hardware open to tampering by malicious actors. The same piece observes that the security of custom-made chips built for specialized business operations is frequently neglected by manufacturers altogether — precisely the kind of bespoke, high-value hardware that enterprises are least equipped to audit on their own.
And the problem is compounding, not shrinking. As more device categories gain connectivity — from medical equipment to industrial control systems to connected vehicles — the number of potential entry points multiplies faster than most security budgets. Every one of those devices eventually shows up as a line item in a procurement request, and every one of them is a decision point that either builds in security or defers it.
The Solution: Negotiate Security Into the Deal, Not Just the Deployment
If the vulnerabilities originate before a device is ever plugged in, the fix has to start at the same point: the purchasing decision itself.
Treat hardware-rooted security as a baseline requirement, not a premium feature. Intel frames hardware-based security not as a replacement for software protections but as a complementary layer that creates a multilayered, comprehensive defense capable of detecting and preventing a wider range of threats than software alone. Buyers should expect — and ask for — this layered approach as a default, not something reserved for premium SKUs.
Push for a hardware-rooted “root of trust” as a specified feature. Analog Devices explains that true hardware security relies on a secure microcontroller executing software from an internal, immutable memory, which is inherently trustworthy because it cannot be modified and can therefore verify and authenticate everything that runs after it. This is a concrete, verifiable technical requirement that a buyer can write directly into a request for proposal — not a vague assurance to take on faith.
Make vendor and supply-chain vetting a formal step in procurement, not an afterthought. ManageEngine’s guidance is explicit: investigate vendors and suppliers of every individual hardware component before selecting them, with detailed inspection of the security measures each one deploys. This due diligence belongs in the sourcing phase of a deal, where it can actually influence vendor selection, rather than surfacing as a post-purchase discovery.
Insist on encryption and attack-surface reduction as delivered defaults. ManageEngine recommends encrypting all hardware and portable devices, noting that modern processors already include built-in components for hardware encryption and decryption with minimal CPU overhead — meaning there is little technical excuse for a vendor to ship unencrypted hardware. The same source advises disabling any unused hardware components that could serve as an attack avenue and disposing of them properly, with policy-level restrictions covering anything that can’t be removed.
Treat manageability and AI-readiness as security features, not just productivity ones. As AI workloads move onto the endpoint, hardware capable of supporting encrypted, isolated processing — rather than only cloud-based AI — becomes a compliance and risk-reduction tool as much as a performance one, and should be evaluated as such in any refresh cycle.
How the Solution Gets Implemented: From RFP to Retirement
Turning this from principle into practice means embedding specific, verifiable requirements at each stage of the hardware lifecycle.
At selection: demand tamper evidence and vendor transparency. Intel recommends looking for devices that integrate hardware-based security at the assembly line and through the processor itself, offering OS-level security capabilities out of the box. It also recommends checking, on arrival, whether the manufacturer verifies the authenticity of certified components and takes baseline “golden measurements” of firmware code before it is sealed prior to transport — a concrete, askable question for any hardware RFP. This pairs directly with ManageEngine’s vendor-investigation guidance: buyers who ask both “how do you secure your supply chain?” and “how do you prove a device hasn’t been tampered with in transit?” are evaluating security as part of the deal itself, not assuming it.
At deployment: verify before trust, and enable what’s already built in. Intel describes modern processors that verify the software responsible for loading firmware and the OS at power-on, refusing to proceed if verification fails — a boot-level control that only works if it’s enabled and checked, not assumed. This matters in practice: TPM-based protections, for instance, often ship present but disabled, meaning IT teams have to actively confirm and activate them rather than assuming compliance out of the box. Deployment checklists should require this verification explicitly, alongside enabling any device attestation and virtualization-based isolation the hardware supports for sensitive tasks like logins or data processing.
In managed environments: extend security through remote administration, not just local controls. Intel points to out-of-band management features, such as keyboard-video-mouse (KVM) access, that let IT administrators deploy patches or take over unattended off-site endpoints even when they’re powered down or unresponsive, strengthening both patch velocity and incident recovery for a distributed workforce. These capabilities should be a named requirement in hardware deals for any organization managing a dispersed or hybrid fleet, since they directly determine how quickly a compromised device can be remediated.
On an ongoing basis: build in layered, physical, and electronic controls together. ManageEngine emphasizes that a comprehensive hardware security plan requires enforcing multiple layers of protection — strong access control for locations housing hardware, and tamper switches on components prone to physical tampering that trigger when a device is opened. None of this is exotic technology; it is a matter of specifying it as a requirement during procurement rather than discovering its absence after an incident.
Where standards exist, use them as leverage — and know their limits. The payments industry offers an instructive case study in both directions. The PCI Security Standards Council maintains the PCI-PTS standard specifically to provide hardware-based security controls for point-of-sale systems, which buyers in that space can cite directly in vendor negotiations. But the broader PCI DSS framework remains software-based, a reminder that compliance certifications should be treated as a floor for a security conversation, not a substitute for one.
Conclusion
The throughline across every source of hardware risk — outdated firmware from under-scrutinized manufacturers, unverified supply chains, unencrypted devices, disabled security features, compliance frameworks that don’t reach the silicon — is that all of it is decided, for better or worse, at the point of purchase. Intel’s framing of hardware-based security as a complement to software, not a replacement for it, and Analog Devices’ case that hardware delivers a fundamentally more robust root of trust than software alone, converge on the same conclusion: security bolted on after deployment can only ever be a partial fix for a problem that starts in the factory and the RFP, not in the server room.
For buyers, that means bringing security stakeholders into every hardware negotiation from the start, and treating questions about firmware verification, supply-chain vetting, and encryption defaults with the same rigor as questions about price and warranty. For vendors, it means being ready to answer those questions in specific, technical terms — because ManageEngine’s blunt assessment that hardware security can no longer be brushed aside and must be considered as seriously as any other security measure is quickly becoming the baseline expectation, not a differentiator. And for cybersecurity leaders, the lesson is that some of the most consequential security decisions an organization makes this year won’t happen in the SOC — they’ll happen in the procurement meeting, long before a single device is ever plugged in.