Enterprise security programs tend to concentrate on the systems that generate the most visible risk: user workstations, servers, cloud workloads, identity providers, and core network infrastructure. Those systems receive endpoint detection, vulnerability scanning, centralized logging, configuration management, and routine incident-response coverage. Yet the same environment can contain hundreds or thousands of devices that sit outside those workflows: multifunction printers, IP cameras, video recorders, VoIP phones, conference-room systems, building controllers, badge systems, baseboard management controllers, and network-managed rack PDUs.
These devices are often treated as appliances rather than computers. From a defensive perspective, that distinction is misleading. Many run embedded Linux or another operating system, expose web interfaces and management protocols, process untrusted network traffic, store data, maintain credentials, contact vendor cloud services, and receive firmware updates. Some can control physical systems or gain privileged access to larger hosts. Their security significance comes from what they can reach, what they can observe, and how little telemetry the security operations center receives from them.
Academic research has demonstrated the consequences at scale. Antonakakis et al.’s analysis of the Mirai botnet documented infections across DVRs, IP cameras, routers, printers, and other embedded systems. Mirai reached a peak population of roughly 600,000 infected devices. The research showed how weak authentication and exposed services on embedded equipment could support attacks far larger than the capability of any individual device might suggest.
Why Forgotten Devices Fall Outside Security Operations
The first failure is usually identification. A laptop normally enters an enterprise through a managed process. It receives an asset record, an owner, an operating-system baseline, an endpoint agent, and a patch policy. A camera, printer, display, thermostat, or badge controller may enter through facilities, physical security, an audiovisual contractor, a managed print provider, or a building vendor. It can receive an IP address and begin communicating without passing through the same security lifecycle.
Research on “shadow IoT” describes this condition directly: connected devices can appear on organizational networks without the IT team knowing they are present. That creates problems for security monitoring and forensic readiness before an attacker ever becomes involved.
IoT Sentinel, an IEEE research project focused on automatic device identification, approaches the problem from the same starting point. The researchers describe IoT equipment that can contain weak security designs and limited firmware-update mechanisms, then propose identifying device types through network characteristics so communication restrictions can be applied according to device risk.
This creates an operational gap between what exists and what the security team can account for. An organization may possess a traditional asset inventory yet still lack a reliable inventory of embedded and cyber-physical equipment. The missing fields are often the ones that matter during an incident: exact model, firmware version, management address, physical location, owner, support status, vendor account, remote-access method, expected destinations, and business function.
NIST’s IoT cybersecurity baseline provides a useful way to frame the problem. It identifies device identification, configuration, data protection, logical access to interfaces, software update, and cybersecurity-state awareness as core capabilities for connected devices. A product that cannot be uniquely identified, securely configured, updated, or observed creates a security-control gap before exploitation begins.
Printers Are Full Network Computers
Printers remain one of the clearest examples. A modern multifunction printer can contain persistent storage, document-processing interpreters, web administration, directory integration, email functions, scan-to-file capabilities, print protocols, and firmware that may remain deployed for years. It can process confidential documents and often sits on a network segment with broad internal reach.
Müller et al. tested 20 printer models for their 2017 IEEE Symposium on Security and Privacy study, SoK: Exploiting Network Printers. Every model in the evaluation was vulnerable to at least one of the attacks tested. The research examined techniques capable of extracting print jobs or system files, manipulating documents, causing denial of service, and abusing the interpreters responsible for processing print data.
Printers also have enough distinct network behavior to justify dedicated intrusion-detection research. Hecht, Sagi, and Elovici built a behavioral detection framework for printer attacks using thousands of benign sessions and malicious interactions across printing protocols. That work reinforces a point that enterprise monitoring often misses: a printer produces security-relevant network behavior even if no endpoint agent can run on it.
The security issue is not that every printer is easily compromised. The problem is the combination of meaningful functionality and poor visibility. Printer logs may never reach the SIEM. Firmware versions may not exist in the vulnerability-management platform. Administrative credentials can remain unchanged for years. A compromised printer can also escape containment if responders examine conventional endpoints and never ask what else occupied the same network segment.
Printers create a particularly awkward trust relationship. Employees routinely send sensitive information to them, directory services may authenticate users against them, administrators manage them remotely, and scan functions can write into file shares or send email. The device sitting beside an office copier can have network relationships that resemble a server far more than a traditional peripheral.
Cameras and Video Systems Carry Network Risk and Sensitive Data
IP cameras and network video recorders create another form of exposure. They are network endpoints equipped with cameras, microphones, local storage, remote administration, vendor applications, and often outbound Internet communication. Their compromise can expose surveillance data and establish an internal foothold at the same time.
A 2022 security assessment of the TP-Link Tapo C200 identified denial-of-service, video-eavesdropping, and a new technique the researchers named the “Motion Oracle” attack. A separate 2024 analysis of the Tenda CP3 used static and dynamic firmware analysis and identified five new CVEs with CVSS scores ranging from 7.5 to 9.8.
The Mirai research provides the large-scale counterpart to those device-specific studies. Cameras and DVRs were part of the embedded-device population recruited into the botnet, showing that surveillance equipment can become useful attack infrastructure once exposed weaknesses are automated.
For enterprise defenders, the main lesson is architectural. Cameras are commonly owned by physical-security teams, installed by integrators, and placed on networks that the SOC may not examine with the same depth as user and server segments. Video systems can also remain deployed far longer than employee workstations, increasing the chance that firmware support ends years before the organization replaces the hardware.
Their data sensitivity raises the stakes further. A compromised camera is not simply another machine from which an attacker can originate traffic. It can expose physical layouts, employee activity, access patterns, restricted areas, recorded video, audio, and operational schedules. The physical-security device can become an intelligence-collection platform against the organization it was installed to protect.
A Second Endpoint Fleet
VoIP phones, smart displays, room controllers, wireless presentation devices, and conferencing systems are easy to overlook since organizations associate them with communications or audiovisual services rather than computing. The network does not make that distinction. These systems can run operating systems, expose web services, use SIP or proprietary protocols, authenticate to cloud platforms, and handle microphones, cameras, contact data, meeting metadata, or account tokens.
Research has treated network printers and VoIP phones as related classes of multi-service embedded devices that can face attacks through poorly secured network services and configurations. Studies of VoIP security have also documented risks involving interception, denial of service, signaling manipulation, and weaknesses within SIP-based environments.
Large-scale smart-device measurements give another view of the issue. The IoT Inspector project collected labeled network traffic from 44,956 smart devices across 53 vendors. Researchers found devices using outdated TLS versions and weak cipher suites. They also identified roughly 350 third-party advertising and tracking domains associated with smart TVs.
A conference-room display is not identical to a consumer smart TV, and a corporate VoIP handset is not identical to a home IoT product. The research still illustrates a recurring property of embedded equipment: these devices can maintain external relationships and expose protocol behavior that is invisible to the person using them.
That becomes more significant in modern meeting spaces. A single room can contain a conferencing appliance, touchscreen controller, display, wireless presentation gateway, camera, microphone array, VoIP integration, occupancy sensor, and environmental controls. Each component can have its own firmware, administrative interface, vendor service, update mechanism, and network identity. From the SOC’s perspective, a conference room may represent a small cluster of computers that nobody classifies as endpoints.
Building Automation, Network Compromise, Physical Events
Building automation systems deserve separate attention since they connect network security to physical operation. HVAC controllers, lighting systems, access systems, environmental sensors, and related controllers can use protocols such as BACnet, KNX, LonWorks, Modbus, ZigBee, and Z-Wave. Many of these technologies emerged from environments where isolation formed a major part of the security model.
A 2023 review in Annual Reviews in Control examined the increased connectivity of commercial building systems, including IP networking, remote management, cloud services, and external integration. The researchers cataloged protocol and architectural weaknesses and described possible attack effects such as signal corruption, signal delay, and signal blocking.
A 2024 review covering seven building-automation protocols found continued security concerns across both legacy protocols and newer security extensions. The study also examined a real building-automation environment and documented weaknesses that persisted across the system.
This class of equipment changes incident impact. A compromised employee workstation may expose information or credentials. A compromised building controller can affect temperature, door access, equipment availability, environmental conditions, or other physical processes.
Security operations also need to account for operational safety. Techniques that work on an office VLAN cannot automatically be transferred to building-control networks. Aggressive scanning, forced reboots, isolation, or firmware changes can interfere with systems that control physical equipment. Detection needs to account for the operating requirements of the underlying process.
Building systems also demonstrate why organizational ownership matters. Facilities teams may know every controller in a building and still have no process for sending those assets into the enterprise vulnerability program. The SOC may see network traffic from a BACnet controller without knowing its physical purpose. Both groups can possess accurate information and still fail to produce a complete security picture if their inventories never meet.
The Computer Inside the Server May Be More Privileged Than the Server
Baseboard management controllers represent an especially serious blind spot. BMCs provide out-of-band administration and appear under product families such as Dell iDRAC, HPE iLO, and Lenovo XCC. They operate separately from the main host operating system and can remain accessible when the host itself is unavailable. That separation makes remote administration possible, but it also places the management controller outside much of the telemetry generated by the server it controls.
Bonkoski, Bielawski, and Halderman examined this problem in their USENIX Workshop on Offensive Technologies research on IPMI. They described the BMC as an embedded computer with its own storage and operating environment, coupled with extensive access to host hardware and management functions. Their analysis of one widely deployed IPMI implementation found serious vulnerabilities, including flaws capable of providing remote root access to the controller.
The persistence implications are particularly significant. The researchers explained that malicious code residing in a BMC could operate below the host operating system and survive actions such as reinstalling that operating system or replacing host storage. A response team could rebuild the server and still leave the lower-level management environment untouched.
Recent research has extended the threat model. A 2024 IEEE paper on BMC firmware analysis described techniques capable of transferring control from the BMC into valuable server resources, including memory, code, files, storage, and firmware through DMA-related access.
PMFault research demonstrated another consequence of excessive BMC privilege. Researchers showed how weaknesses involving BMC-accessible management interfaces and motherboard components could support hardware fault-injection attacks against server CPUs, including conditions capable of damaging the system.
This creates an unusual security problem: a server can have excellent EDR coverage and still contain a lower architectural layer that the EDR cannot meaningfully inspect. BMC segmentation, credential management, firmware tracking, remote-access restrictions, and management-plane monitoring belong inside the server security model.
Even Rack Infrastructure Can Become a Network Target
Network-managed rack PDUs and related infrastructure devices are another category that can enter through data-center operations rather than the SOC. These systems can offer remote switching, environmental monitoring, web management, SNMP, and other network services. Their compromise can affect availability in ways that have little resemblance to a conventional endpoint incident.
A 2024 academic study examined the network security of an intelligent PDU and subjected the device to several TCP denial-of-service conditions. The work demonstrates that equipment traditionally viewed as supporting infrastructure can expose network services and security properties that require direct assessment.
The same reasoning applies to environmental sensors, console servers, KVM systems, remote terminal units, storage-management appliances, and specialized controllers. The useful security question is not whether the device resembles a computer. It is whether the device executes code, communicates across the network, stores information or credentials, accepts remote commands, or can affect another system.
If the answer is yes, the device belongs in the attack-surface model.
Asset Inventory and Detection Function
The strongest defensive response begins with continuous discovery rather than treating asset inventory as a spreadsheet exercise. Security teams can compare DHCP records, DNS activity, ARP tables, switch MAC tables, wireless-controller data, NAC records, flow telemetry, vulnerability scans, and passive network monitoring to identify devices absent from the primary asset system.
Passive techniques are particularly valuable around fragile operational equipment where active scanning can affect availability. Device-fingerprinting research such as IoT Sentinel also demonstrates how observable network characteristics can help classify unknown equipment when administrative records are incomplete.
Identification needs to go deeper than an IP address and MAC manufacturer. A useful asset record should describe the device class, vendor, model, firmware version, owner, physical location, network segment, management interface, authentication method, support status, expected external destinations, expected internal peers, and available logging capabilities.
Security teams can then move from discovery into behavioral monitoring. Many embedded systems have narrowly defined jobs. That can make meaningful deviations more visible once normal behavior is established. A printer beginning repeated outbound communication with unfamiliar infrastructure, a camera scanning internal address ranges, or a BMC initiating connections outside its management network should receive investigation.
DNS records, flow telemetry, authentication events, configuration changes, management logins, and egress activity can provide useful detection signals even when installing an endpoint sensor is impossible. This changes the detection question from “Can we run EDR on this?” to “What telemetry exists around this device, and what would abnormal behavior look like?”
Segmentation Limits What a Forgotten Device Can Become
Network architecture becomes especially valuable once embedded systems are identified. Cameras have little reason to initiate arbitrary connections to employee workstations. Printers rarely require unrestricted east-west access. Building controllers rarely need direct communication with random corporate endpoints. BMC interfaces belong on tightly controlled management networks rather than ordinary server or user segments.
Function-based segmentation gives defenders a way to contain devices that cannot support modern endpoint controls. Access rules can permit required management systems, business services, vendor connections, and known dependencies, then block or inspect traffic outside that profile.
Egress deserves equal attention. A device that needs access to three vendor services should not automatically receive unrestricted Internet connectivity. Restricting external communication can reduce exposure to command-and-control infrastructure, opportunistic scanning, unauthorized cloud services, and vendor dependencies that were never formally evaluated.
Segmentation also creates better detection context. A connection that appears unremarkable on a flat enterprise network can become immediately suspicious if policy states that a camera VLAN should communicate only with video-management servers, DNS, NTP, and a defined vendor service.
Firmware and Vulnerability Management
Traditional vulnerability management is heavily oriented around operating systems and applications. Embedded-device risk is frequently tied to exact hardware revisions, firmware versions, vendor support periods, and proprietary components.
Security teams need a method for mapping discovered devices to firmware versions and vendor advisories. End-of-support dates need to be recorded. Update procedures need to be known before a serious vulnerability appears. Products that cannot be patched need documented compensating controls or replacement plans.
Firmware deployment can also require more care than workstation patching. Cameras, industrial controllers, building systems, and infrastructure appliances may have operational dependencies that make untested updates risky. The answer is not to avoid updates indefinitely. It is to incorporate these systems into a controlled process where operational owners and security teams both understand the risk.
Procurement offers a chance to prevent future blind spots. NIST’s IoT baseline provides a useful set of requirements for evaluating new connected products: unique identification, secure configuration, restricted logical interfaces, data protection, supported software updates, and sufficient security-state information for monitoring.
A product that cannot support those requirements transfers the security burden back to the organization. Procurement teams should know that before the device is installed, not five years later when responders discover it during an incident.
Incident Response Below the Operating System
Forgotten devices also require different response assumptions. Reimaging a workstation can remove many forms of endpoint compromise. That model does not transfer cleanly to a compromised camera, printer, building controller, or BMC.
Response may require network isolation, firmware validation or reinstallation, factory-reset procedures, credential rotation, vendor-account review, replacement of unsupported hardware, and investigation of any systems the device could reach.
BMC incidents provide the clearest example. Rebuilding the host operating system does not establish that the management controller is clean. Printer incidents may require investigation of stored documents, address books, directory credentials, and scan destinations. Camera incidents can involve recorded video, account credentials, remote vendor services, and privacy exposure. Building-system incidents can require coordination with facilities personnel before containment actions alter device availability.
Security teams need response playbooks that identify those dependencies before an incident occurs. Discovering that a device has no documented owner, no tested recovery procedure, no known firmware source, and no recorded network dependencies after compromise places the response team at a major disadvantage.
The Real Blind Spot Is the Definition of an Endpoint
The devices security teams forget to watch are rarely invisible in a literal sense. They appear in DHCP leases, switch tables, DNS activity, wireless controllers, vendor portals, maintenance contracts, and physical spaces. They become invisible when security programs define an endpoint too narrowly.
A useful defensive model treats any networked device that executes code or can affect another system as part of the attack surface. That includes the printer outside the conference room, the camera above the door, the VoIP phone on the desk, the controller above the ceiling tiles, the PDU in the rack, and the BMC inside the server.
The academic record across these device classes points to a recurring operational problem. Embedded systems can carry meaningful privilege, access sensitive information, communicate with external infrastructure, and affect physical processes without receiving the controls routinely applied to workstations and servers.
The answer is not to force conventional endpoint security onto every device. In many cases, that cannot be done. The better objective is complete visibility: know the device exists, know who owns it, know what it should communicate with, know how it is updated, restrict what it can reach, and collect enough network or management telemetry to recognize meaningful changes in behavior.
A security program that monitors every laptop but cannot account for the computers hidden inside its cameras, printers, conference rooms, buildings, racks, and servers still has an endpoint visibility problem. It has simply been looking for endpoints in the wrong places.
How Can Netizen Help?
Founded in 2013, Netizen is an award-winning technology firm that develops and leverages cutting-edge solutions to create a more secure, integrated, and automated digital environment for government, defense, and commercial clients worldwide. Our innovative solutions transform complex cybersecurity and technology challenges into strategic advantages by delivering mission-critical capabilities that safeguard and optimize clients’ digital infrastructure. One example of this is our popular “CISO-as-a-Service” offering that enables organizations of any size to access executive level cybersecurity expertise at a fraction of the cost of hiring internally.
Netizen also operates a state-of-the-art 24x7x365 Security Operations Center (SOC) that delivers comprehensive cybersecurity monitoring solutions for defense, government, and commercial clients. Our service portfolio includes cybersecurity assessments and advisory, hosted SIEM and EDR/XDR solutions, software assurance, penetration testing, cybersecurity engineering, and compliance audit support. We specialize in serving organizations that operate within some of the world’s most highly sensitive and tightly regulated environments where unwavering security, strict compliance, technical excellence, and operational maturity are non-negotiable requirements. Our proven track record in these domains positions us as the premier trusted partner for organizations where technology reliability and security cannot be compromised.
Netizen holds ISO 27001, ISO 9001, ISO 20000-1, and CMMI Level III SVC registrations demonstrating the maturity of our operations. We are a proud Service-Disabled Veteran-Owned Small Business (SDVOSB) certified by U.S. Small Business Administration (SBA) that has been named multiple times to the Inc. 5000 and Vet 100 lists of the most successful and fastest-growing private companies in the nation. Netizen has also been named a national “Best Workplace” by Inc. Magazine, a multiple awardee of the U.S. Department of Labor HIRE Vets Platinum Medallion for veteran hiring and retention, the Lehigh Valley Business of the Year and Veteran-Owned Business of the Year, and the recipient of dozens of other awards and accolades for innovation, community support, working environment, and growth.
Looking for expert guidance to secure, automate, and streamline your IT infrastructure and operations? Start the conversation today.
Netizen Blog and News 
Leave a comment