Glossary of Terms

A security weakness in a physical device or its embedded software (firmware) that can be exploited by an attacker. Unlike software vulnerabilities on general-purpose computers, hardware vulnerabilities often cannot be fixed by the device owner — only by the manufacturer. The increasing number of connected devices in homes and organizations (IoT, embedded systems, industrial controls) has dramatically expanded the attack surface of hardware vulnerabilities.

The specialized software embedded within a hardware device that controls its basic functions — essentially the operating system of the device. Firmware is tightly coupled to the hardware and cannot be updated by end users through standard OS patching procedures. Only the manufacturer can release firmware updates. If the manufacturer does not release a patch for a vulnerability, the vulnerability remains unaddressed regardless of any other security measures the device owner takes. Examples: firmware in routers, IP cameras, smart thermostats, industrial controllers, HVAC systems.

The broad category of everyday physical objects connected to the internet or a network, enabling remote monitoring, control, and data exchange. IoT devices include smart home appliances (thermostats, light bulbs, door locks, refrigerators), industrial sensors, IP cameras, badge readers, environmental monitors, and medical devices. IoT devices typically run firmware rather than general-purpose operating systems, have limited user interfaces, and receive infrequent updates — making them a significant and growing source of hardware vulnerabilities.

The point at which a manufacturer stops selling a product. At EOL, the product is no longer available for new purchase, but the manufacturer may still provide ongoing support — including security patches, bug fixes, and technical assistance. EOL is a planning signal: the device is still supported but the countdown to full end of support has begun. Organizations should begin planning replacement at EOL to avoid reaching EOSL without a migration path in place.

The point at which a manufacturer stops all support for a product — including security patches, bug fixes, and technical assistance. At EOSL, the device is no longer sold AND no longer supported. Any vulnerabilities discovered after the EOSL date will not be patched by the vendor. The device's firmware is permanently frozen at its last supported version. EOSL represents a critical security threshold: the device accumulates unpatched CVEs indefinitely with no path to remediation. Some vendors offer costly premium support extensions beyond EOSL, but these are temporary and expensive.

A hardware device or software system that remains in use beyond its intended operational lifecycle — often running an older operating system, outdated firmware, legacy middleware, or end-of-life software. Legacy platforms frequently remain deployed because replacement is expensive, operationally disruptive, or technically complex. While they may still function correctly for their intended purpose, their security posture deteriorates over time as new vulnerabilities are discovered and no patches are released. Organizations typically apply compensating controls (firewall rules, IPS signatures, network segmentation) to manage risk while planning replacement.

A security measure applied to reduce the risk of a vulnerability that cannot be directly remediated. For EOSL or legacy hardware devices, compensating controls replace the patches that are no longer available. Common examples include: restricting firewall rules to allow only necessary traffic to the device; deploying IPS signatures targeting known exploits for the specific firmware version; isolating the device in a separate VLAN or network segment with limited connectivity; and monitoring traffic to/from the device for anomalous behavior. Compensating controls reduce risk but do not eliminate the underlying vulnerability.

The practice of placing vulnerable or legacy hardware devices in isolated network segments (VLANs) that restrict their connectivity to only the systems that legitimately need to communicate with them. Segmentation limits the blast radius of a compromised device — even if an attacker exploits a firmware vulnerability, their lateral movement is constrained by the network boundaries around the device. Segmenting IoT and legacy devices away from production systems and the corporate network is a fundamental hardware security best practice.

Intrusion prevention system detection rules written specifically for known vulnerabilities in older firmware versions or operating systems. Since legacy and EOSL devices cannot be patched, IPS signatures at the network layer can detect and block known exploit traffic targeting those devices. Vendors and security researchers publish IPS signatures for commonly exploited legacy platforms. These signatures do not fix the vulnerability but prevent known attack patterns from reaching the device.

A real-world example of hardware firmware vulnerability and slow vendor response. Three security vulnerabilities in the Trane ComfortLink II smart thermostat were disclosed to Trane in April 2014. The first two patches were released in April 2015 — one year after disclosure. The third patch was not released until January 2016 — nearly two years later. During this period, all unpatched thermostats remained vulnerable. The case illustrates the dependency on manufacturers for firmware patches and the risk of extended patch delays in hardware devices compared to traditional operating systems.