How To Discover IoT Devices with Shodan

IoT devices rarely show up in a normal inventory until something breaks, gets exposed, or ends up on the public internet by mistake. If you need to know how to find cameras on Shodan or locate routers, NAS boxes, printers, and industrial controllers that outsiders can already see, this guide gives you a repeatable, defensive workflow.

Primary Use	Exposure assessment and IoT asset discovery as of October 2026
Typical Targets	IP cameras, routers, NAS devices, printers, smart-home gear, and industrial controllers as of October 2026
Best Evidence	Service banners, hostnames, ports, and metadata as of October 2026
Main Filters	product, port, country, city, org, and hostname as of October 2026
Use Case	External attack surface review, incident response, and continuous monitoring as of October 2026
Risk Focus	Management interfaces, outdated firmware, and unexpected public exposure as of October 2026

What Shodan Is And Why It Matters For IoT Discovery

Shodan is a search engine for internet-facing services, not websites. Instead of indexing pages the way Google does, it records banners, ports, protocol responses, hostnames, and other metadata that devices expose on the public internet.

That difference matters because many IoT devices never appear in a browser search, yet they still expose services such as web admin panels, RTSP streams, SSH, Telnet, or proprietary management ports. A camera with no public website can still be visible to Shodan if it answers on port 80, 443, 554, or another service port.

This is why Shodan is useful for Asset Discovery and external exposure reviews. It can reveal forgotten devices, misconfigured systems, and Shadow IT that never made it into the official inventory.

Exposure does not automatically mean compromise, but exposed services are often the first link in an attack chain.

For defenders, that visibility is the point. A public IP camera, printer, or industrial controller may be perfectly legitimate inside a network, but once it is visible from the internet, it deserves review. That is exactly the kind of security work covered in practical ethical hacking training, including the CEH v13 course context where discovery and validation come before any testing.

According to the National Institute of Standards and Technology, asset visibility is a core part of identifying risk. In the same spirit, CISA maintains a catalog of known exploited vulnerabilities that makes public exposure even more important to track.

What Shodan can reveal

• Webcams and IP cameras with live-view interfaces or device login pages.
• Routers with remote administration or legacy services.
• Industrial systems such as controllers, gateways, or SCADA-related interfaces.
• NAS devices with exposed management consoles or file services.
• Printers and building systems that expose web management or telemetry ports.

When Should You Use Shodan For IoT Asset Discovery?

Use Shodan when you need to answer a simple question: what of ours is visible to the internet right now? That makes it useful for external attack surface reviews, post-merger cleanup, branch-office audits, and vendor deployments where the ownership of devices is unclear.

It is also valuable after an incident. If a camera family, remote access service, or industrial controller model becomes a concern, Shodan can help you determine whether that type of device is publicly reachable anywhere in your environment. That turns a vague concern into a concrete remediation list.

One of the strongest use cases is continuous monitoring. A one-time check catches a snapshot. Repeated checks catch the devices that are added later without approval, the ports that were opened for troubleshooting and never closed, and the services that drift out of policy.

According to the U.S. Bureau of Labor Statistics, security analysts are expected to stay busy because organizations keep expanding their external footprint. That workload is one reason defensive discovery needs a repeatable process instead of ad hoc searching.

Good times to run a Shodan review

• After an office move or network readdressing.
• After a vendor installs cameras, printers, or building controls.
• After a merger or acquisition when inventories are incomplete.
• During quarterly exposure reviews.
• When you need to verify whether a remediation actually worked.

Keep the line clear between authorized review and unauthorized access. Searching public data for your own exposure is legitimate. Using findings to probe, exploit, or interact with systems you do not control is not.

Getting Started With A Shodan Account

A Shodan account gives you a search interface, saved queries, and a place to organize results. Start simple. The first job is not to build a perfect query; it is to understand how results are structured and what metadata Shodan returns.

Free access is enough to learn the interface and test basic searches, but deeper workflows often require more history, better result handling, or API use. The exact limits change over time, so check the current plan details before you build a long-term process around the free tier.

Focus on three areas in the dashboard: saved searches, result inspection, and settings related to API access or organization details. If you are doing this for work, document the query name, purpose, date, and owner from the start. That makes handoff much easier later.

For official product details, use Shodan. If your workflow expands into automation, keep your internal documentation aligned with the exact query syntax you are using so results stay repeatable.

Set up a basic workflow

1. Create an account and confirm you can run searches.
2. Save one broad query for cameras or IoT devices.
3. Record what the result fields mean in your own notes.
4. Build a second query for your organization’s public ranges or known vendors.
5. Track findings in a ticketing or spreadsheet workflow.

How Does Shodan Index IoT Devices?

Shodan scans public IP space and stores the responses it receives from exposed services. Indexing is the process of capturing those service details so they can be searched later by product, banner text, port, hostname, country, and other filters.

The key point is that a device does not need a webpage to be visible. A camera can identify itself through an HTTP header, a router can reveal its model in a login page title, and an industrial controller can disclose a protocol fingerprint or version string on another port.

Different services reveal different clues. Web admin pages may show brand names, firmware versions, or model numbers. SSH and Telnet banners may expose a software family. RTSP often helps identify video devices. Proprietary industrial services may expose enough metadata to indicate a controller family even when the interface is unfamiliar.

According to Shodan, public services are indexed based on what they expose, not on what the owner intended to publish. That is why stale lab gear, remote management portals, and forgotten embedded systems can appear in results long after they were deployed.

What the banner tells you

• Device family when the banner includes a recognizable vendor or product name.
• Firmware version when the response includes version text or build numbers.
• Service type when the port clearly maps to HTTP, SSH, RTSP, or another protocol.
• Deployment clues when hostnames or headers hint at office, plant, or branch use.

Building Effective Search Queries For IoT Devices

The fastest way to learn how to find cameras on Shodan is to start broad and narrow the search only after you see the result patterns. If you begin too narrowly, you miss devices that use different banners or slightly different firmware strings.

A practical starting point is to search by device type, vendor name, service, or common port. For cameras, that often means looking at HTTP, RTSP, or device-specific product text. For routers, you may search by remote management keywords, known vendor banners, or admin panel titles. For industrial systems, a protocol name or controller family may be more useful than a brand name alone.

Once you have a small set of obvious results, refine the query with additional terms. Use phrase matching when the banner text is distinctive. Use simpler search terms when the device exposes minimal metadata. The best query is the one that returns a manageable list you can actually review.

Example search angles

• Device type: camera, webcam, printer, router, NAS.
• Service clue: RTSP, HTTP, SSH, Telnet, remote admin.
• Vendor clue: the manufacturer name from a known banner or login page.
• Protocol clue: industrial or building-control service identifiers.

Broad Search	Useful for discovery, but often noisy because it returns many unrelated internet-facing services.
Narrow Search	Useful for validation, because it reduces noise and highlights devices that match a known pattern.

Shodan is not the only iot search engine people use in conversation, but it is the one most defenders reach for when they need searchable exposure data. That matters when you are reviewing public-facing assets rather than browsing a general web index.

If you are documenting work for a report or a ticket, save the exact query string. That lets someone else repeat the search later and verify whether a finding still exists.

Using Filters To Narrow IoT Results

Filters are what turn noisy search results into something useful. If you only search by “camera,” you will get everything from webcams to industrial vision systems. Filters help you isolate the subset that belongs to your environment or region.

The country: filter is useful when you need to review exposure in a specific geography. The city: filter helps when you are looking at a branch office, metro area, or local deployment. The org: filter can help connect devices to a known organization or hosting provider when the data is available.

The product: filter is one of the most valuable because it reduces unrelated noise. If a service fingerprint is accurate, the results become much easier to review. Layering filters is usually better than stacking too many search words into one long query.

This is also where people start checking for iot devices near me in the practical sense of nearby offices, branches, or sites they manage. The goal is not curiosity. The goal is to identify unmanaged exposure before someone else notices it first.

How to layer filters

1. Start with the device or service type.
2. Add one geographical filter if location matters.
3. Add a product or vendor clue to reduce noise.
4. Review a small sample before tightening further.

That same layered approach works well when you are trying to separate corporate assets from third-party hosting or shared infrastructure. If the result set is still too broad, remove one term at a time and compare the difference.

How To Find Cameras On Shodan Without Chasing Noise

To how to find cameras on Shodan effectively, search for the service behavior that cameras commonly expose, not just the word “camera.” Many IP cameras reveal themselves through web login pages, RTSP services, or vendor-specific banners that identify the model family.

In practice, you are looking for combinations like a web interface plus a camera-oriented banner, or RTSP plus a vendor string that suggests a video device. A camera with remote admin access may also expose other ports, which is useful for classification and risk scoring.

Common error: assuming every result on port 80 is a camera. Many printers, routers, DVRs, and NAS devices also use HTTP. That is why the page title, favicon, login text, and response headers matter. They help you decide whether the host is a camera, a recorder, or something else entirely.

A good camera search is a classification exercise, not a keyword hunt.

Practical clues to look for

• RTSP on port 554 combined with a video-related login page.
• HTTP headers that expose a vendor or firmware family.
• Login text that references imaging, surveillance, or NVR functions.
• Hostnames that hint at physical security, building systems, or site names.

If you work in a security team, this is one of the easiest places to demonstrate value quickly. A small number of exposed cameras can tell you a lot about whether remote administration, contractor access, or old test hardware is still hanging around outside policy.

Finding Routers, Industrial Controllers, And Other Overlooked Devices

Routers and industrial controllers often get missed because they are not “user-facing” assets, but they can be some of the highest-risk devices on the internet. A router with remote admin enabled, or a controller with an exposed management page, deserves immediate review.

For routers, look for management pages, vendor web interfaces, or service banners tied to remote administration. For industrial systems, the clues may be less obvious. You may see a web dashboard, a proprietary service, or a hostname tied to a plant, line, or facility.

Other frequently overlooked devices include printers, NAS appliances, building controls, and smart-home equipment used in offices or labs. These devices often have long lifecycles, weak patch discipline, and inconsistent ownership. That makes them easy to forget and hard to track.

According to the Cybersecurity and Infrastructure Security Agency, exposed internet-facing devices can become entry points when they are not maintained. That is why external discovery should be paired with ownership and patch review.

What to check before you classify the device

• Port mix: a single service is less informative than multiple exposed ports.
• Page title: often more useful than the IP address alone.
• Vendor text: may reveal model family or device category.
• Deployment context: office, lab, plant, retail, or remote site.

How Do You Read Banners, Hostnames, And Open Ports?

The first answer to how do you identify an IoT device in Shodan is to read the metadata carefully. Banners tell you what service answered. Hostnames may hint at where the device lives. Open ports reveal how much of the device is exposed.

Metadata is the supporting context that helps you classify the result. A banner might mention a vendor. A hostname might include a site code. A port combination might suggest web admin, remote shell, or a streaming service. None of those clues is enough alone, but together they create a strong picture.

Multiple ports on one host often mean the exposure surface is bigger than expected. A camera with HTTP and RTSP is more interesting than a single web page. A router with SSH, Telnet, and a web panel is a higher priority than a device exposing only a status page.

Cross-check everything against internal records before making a final call. A field device might look like a camera but actually be a recorder. A host that looks like a printer could be a multifunction device with a scan-to-email service and an embedded management page.

Reading clues in practice

1. Start with the banner and note the service name.
2. Check the hostname for site, vendor, or deployment hints.
3. Review the port list for management or shell access.
4. Compare the result with your inventory and procurement records.
5. Classify the device only after the evidence lines up.

How Should You Prioritize Shodan Results By Risk?

Prioritize the results that can be used to manage or alter a device, not just view it. Exposed admin panels, remote shells, and monitoring consoles should rise to the top because they give an attacker more control than a read-only interface.

Outdated firmware and software versions are another strong signal. Public exposure plus known weaknesses is a bad combination, especially when the device handles video, access control, or industrial operations. If the service banner shows an old version, you should treat that as a higher-priority review item.

Business impact matters too. A camera in a lobby is sensitive, but a camera in a production line, a storage room, or a critical facility may have a larger operational or privacy impact. One exposed device may also indicate a pattern, especially if there are multiple hosts with similar banners or the same vendor.

Do not build a giant list and stop there. Turn the list into a remediation queue. Assign owners, set deadlines, and note the evidence that made each finding actionable.

Simple risk ranking rules

• High: exposed management interface, shell access, or known vulnerable version.
• Medium: exposed service with limited control but clear public reachability.
• Low: informational exposure with minimal management capability.

That triage logic is consistent with defensive frameworks used in exposure management and aligns with the practical mindset promoted in ethical hacking work: find, verify, prioritize, then remediate.

Can You Use Shodan For Repeat Monitoring?

Yes. Repeat monitoring is one of the best reasons to use Shodan in the first place. A saved search lets you check whether a device is still exposed, whether a remediation changed the banner, or whether a new device appeared without approval.

Run the same query on a schedule and compare the results over time. If a camera disappears after remediation, that is good. If it reappears a month later, you may have a configuration drift problem or a change that was never documented.

Repeat checks are also useful after patching. A software update may change the banner or version string, but if the service is still public, the exposure problem may remain. The service can be “better” and still be exposed.

For operational teams, this becomes part of Continuous Monitoring. The aim is not a one-time cleanup. The aim is to catch new exposures quickly enough that they never become a larger incident.

What to watch over time

• New hosts that match your device patterns.
• Banner changes that suggest firmware updates or drift.
• Ports that appear or disappear without a change request.
• Devices that reappear after being removed from the network.

How Can Shodan Maps And Geographic Clues Help?

Shodan Maps can help you spot concentration risk. If a site, branch, or region has a cluster of exposed devices, that pattern may point to a local deployment habit, a vendor default, or a weak operational process.

Use location data carefully. It is useful for prioritization, but it is not a substitute for internal records. A city or region in Shodan should be treated as a clue, not as final proof of physical location.

Geographic views are helpful when leadership wants a simple visual summary. It is easier to explain “these three locations have the highest exposure density” than to hand over a spreadsheet of raw IPs.

This can also support conversations with facilities, operations, or third-party vendors. A map makes the issue visible in a way that a list of hostnames sometimes does not.

Use maps to answer these questions

• Which site has the most exposed devices?
• Are exposures clustered in one provider or one office type?
• Do certain regions still show legacy hardware?
• Is there a repeat pattern across branches?

How Do You Automate Shodan Workflows Without Losing Accuracy?

Automation is useful when you need to run the same checks again and again. The Shodan API can support scheduled inventory checks, alerting, reporting, and integration with ticketing or vulnerability management systems.

But automation should not replace validation. A search result can be misleading if the banner is generic, the service is shared, or a host is behind a network translation layer. That is why the best workflow combines automated collection with human review.

In a mature process, results flow into a queue, are reviewed for confidence, and then move into remediation tracking. That is where you tie exposure data to asset management or incident response. A finding should not just be “noted.” It should create action.

If you are building this into a broader security process, align it with the organization’s asset inventory and external exposure review cadence. That makes the data useful beyond the security team and helps other teams act on it faster.

Practical automation use cases

• Scheduled checks for known camera or router patterns.
• Alerts when a previously closed service reappears.
• Weekly reports for leadership or operations.
• Ticket creation when a high-risk device is found.

What Should You Document Before Handing Off A Finding?

Good documentation turns a Shodan result into a fixable issue. At minimum, record the IP address, hostname, detected service, vendor clues, and the reason you believe the device is exposed. If the result is ambiguous, note the uncertainty instead of overstating it.

Attach screenshots or exported evidence when appropriate. The owner who gets the ticket should not have to guess why the issue matters. If you can show the login page, the banner, or the exposed port list, you make remediation easier.

Then map the issue to the right owner. A camera in a branch office may belong to IT, facilities, physical security, or a vendor. A building system may belong to operations. If you send the finding to the wrong group, it will sit untouched.

Track the status until the device no longer appears in Shodan. Remediation is not complete when a ticket is opened. It is complete when exposure is gone and the change has been verified.

Minimum handoff fields

• IP address and hostname.
• Service and exposed port.
• Observed banner or page title.
• Risk reason and recommended action.
• Owner and due date.

What Are The Most Common Mistakes To Avoid?

The biggest mistake is assuming every exposed result is malicious or compromised. That is not what Shodan tells you. It tells you that something is visible and likely worth review.

A second mistake is using only one search term. A single keyword can miss devices that identify themselves differently. Broader and narrower searches often reveal different pieces of the same exposure picture.

Noise is another problem. Shared hosting, NAT, generic banners, and default pages can produce false assumptions if you do not validate the result. Time also matters. Public exposure changes quickly, so any report should be time-bound.

Finally, keep the work defensive. The right goal is to understand exposure, reduce risk, and close gaps. The wrong goal is to probe systems you do not own or have permission to test.

Conclusion

Shodan is most useful when you treat it as a visibility tool for exposure assessment and asset discovery. It helps you find public IoT devices that normal inventories miss, especially cameras, routers, printers, NAS appliances, and industrial controllers.

The workflow is straightforward: search broadly, narrow with filters, inspect banners and hostnames, prioritize the riskiest devices, and document what needs to be fixed. If you repeat that process on a schedule, you turn a noisy search engine into a practical control for reducing exposure.

If you need a skill set that fits this kind of work, the CEH v13 course context is a strong match because it reinforces discovery, validation, and defensive thinking. The real payoff comes when the findings leave the spreadsheet and become closed tickets, removed exposure, and verified remediation.

If you are ready to improve your own process, start with one saved search today and compare the results to your asset inventory. Seeing what the internet can see is often the fastest way to learn what your internal tools missed.

CompTIA®, Cisco®, Microsoft®, AWS®, ISC2®, ISACA®, PMI®, and EC-Council® are trademarks of their respective owners. CEH™, Security+™, A+™, CCNA™, CISSP®, and PMP® are trademarks of their respective owners.