Stephen Cravey’s path toward researching the security of tiny computers embedded in everyday objects started with something considerably larger: his apartment door.
After moving into an apartment with mandatory electronic locks, Cravey, a principal security advisor and longtime member of the CYBR.SEC.Community, started looking into how the locks were managed, updated and patched.
Then a critical vulnerability surfaced involving the Bluetooth library used by the system-on-chip inside the locks. Cravey wanted to know whether his apartment complex had updated them. Getting an answer proved considerably harder.
“I couldn't get the property management to even discuss whether or not they had applied updates to the locks or whether or not they knew” about the vulnerability, Cravey told CYBR.HAK.CAST hosts Phil Wylie and Michael Farnum.
Full episode and related article:


Instead, he encountered a familiar security problem: responsibility belonged to somebody else, or the technology supposedly took care of itself.
“It just became sort of this blame circle of, you know, that's not our responsibility, that's somebody else's problem, or it happens automatically and we don't have to think about it,” Cravey said.
That frustrating experience eventually helped inspire Cravey’s master's thesis and the research behind his upcoming CYBR.SEC.CON 2026 presentation. And the problem extends far beyond electronic door locks.
Full coverage of CYBR.SEC.CON:

We keep putting computers into everything
Microcontrollers and systems-on-chip now sit inside an enormous range of products that most people would never think of as traditional computing devices.
Toothbrushes. Water flossers. Washing machines. Vacuums. Cravey even found a Bluetooth-enabled garden rock while conducting his research.
“It's bonkers, the stuff that people have put microprocessors in and have internet-enabled,” he said.
The novelty of an internet-connected toothbrush may be good for a laugh. The underlying security issue isn't.
Organizations have spent decades building security programs around computers, servers and eventually mobile devices. They can deploy endpoint agents, collect logs, monitor processes and look for signs that software has been modified. That model doesn't necessarily translate to the small processors embedded in connected devices. Cravey compares the problem to challenges security teams already face in operational technology environments.
“You can't run antivirus on [them], you can't really stick a Splunk agent on them,” he said.
That leaves defenders with “very, very limited visibility into what's happening on the device” and limited ability to determine whether it is still running the software it is supposed to be running. The problem can work in the opposite direction as well.
Manufacturers shipping hardware may need to worry about whether someone with physical possession of the device can extract its software and reverse engineer it, potentially exposing intellectual property.
Once hardware leaves the manufacturer's control, Cravey noted, physical access gives its new owner considerable opportunity to examine what's inside.
The toothbrush isn't really the point
It's tempting to dismiss some of this because the devices sound trivial. After all, who cares whether a toothbrush is connected to Wi-Fi?
But Cravey's concern isn't that attackers are assembling armies of malicious toothbrushes. It's what happens when organizations and consumers surround themselves with computers they don't necessarily recognize as computers.
“If you're going to have a device in your network someplace, like an electronic toothbrush, what can you do with a Bluetooth or Wi-Fi enabled device that has no anti-malware capability, you have no visibility into what's actually running on it and it's got access to your local wireless environment?” Cravey said.
Network segmentation can help. Farnum noted during the discussion that his connected appliances operate on a separate network.
But even segmented devices communicate outward to cloud services and back to applications on phones and other systems. Cravey also pointed to the information such devices can potentially collect, including nearby SSIDs and MAC addresses, which can be used for geolocation.
There's another reason manufacturers keep connecting things. Data.
Cravey said many devices appear to have little reason for internet connectivity beyond collecting information about utilization: how often someone uses a product, when they use it and other behavioral patterns that can become another component of that person's data footprint.
What happens when the device itself can't protect itself?
The research behind Cravey's CYBR.SEC.CON talk focused heavily on smaller IoT devices, particularly those without conventional operating systems and which instead run a single program on relatively simple architectures.
What he found wasn't especially reassuring.
“Most of those devices don't really have support for any type of security mechanisms,” Cravey said.
For devices that do offer protections, documentation or other limitations can make those capabilities difficult to understand and use.
That creates questions on both sides of the technology supply chain.
Manufacturers need to understand the security capabilities of the components they're putting into their products.
Enterprises need to understand the capabilities of the devices they're bringing onto their networks.
And somebody eventually has to answer the question Cravey couldn't get answered about the electronic lock protecting his apartment:
When a vulnerability is discovered in that tiny computer, who is responsible for fixing it?
Because the garden rock may sound ridiculous.
The computer inside it is still a computer.


