How To Discover IoT Devices with Shodan

Finding an exposed camera, router, or industrial controller before an attacker does is the point of discover IoT work with Shodan. Shodan is a search engine for internet-connected devices and services, which makes it useful for exposure assessment, asset discovery, and threat research when you need to see what the public internet can already see.

Tool	Shodan
Primary Use	Discover internet-exposed devices and services for authorized exposure assessment
Best For	Webcams, routers, industrial systems, smart home devices, and exposed services
Free Access	Limited search and account features as of June 2026
API Key	Available from the account dashboard for automation and integrations as of June 2026
Maps View	Useful for geographic pattern analysis as of June 2026
Primary Risk	Exposed management interfaces, weak defaults, and forgotten assets

What Shodan Is And Why It Matters For IoT Discovery

Shodan is an internet-wide search engine that indexes exposed services, open ports, banners, and metadata from connected devices. Unlike Google, which indexes web pages, Shodan indexes the service layer that sits behind an IP address. That matters because many IoT devices never show up in normal web search results, yet they still expose a login page, a camera feed, an admin interface, or a remote management port.

For a cybersecurity professional, that visibility is practical. You can use it to uncover forgotten webcams in a branch office, a router still exposing Telnet, or a building controller with a public web interface. For a network administrator, Shodan helps answer a simple but important question: what did we accidentally leave on the internet?

Exposure is not the same as compromise, but exposed IoT services are often the first link in a bigger attack chain.

Shodan commonly reveals cameras, routers, industrial control systems, NAS appliances, printers, and smart-home gear. It can also expose databases, remote desktop services, and VPN gateways that were never meant to be publicly reachable. That makes it valuable for attack surface management, incident response, and security research.

For context on why this matters, the Cybersecurity and Infrastructure Security Agency (CISA) consistently pushes basic exposure reduction and asset visibility as core defense practices, and the NIST Computer Security Resource Center emphasizes inventory and configuration control in its guidance. If you are studying these workflows in the CompTIA Pentest+ Course (PTO-003) | Online Penetration Testing Certification Training, this is the same mindset used in professional assessment planning.

Prerequisites

Before you start, make sure you have the right access and a clear scope. Shodan is easy to use, but useful results depend on good queries and disciplined handling of data.

• A Shodan account for search access and saved queries.
• Authorization to assess the assets you are reviewing.
• Basic TCP/IP knowledge so you can interpret ports, banners, and hostnames.
• A working inventory or target list if you are checking your own environment.
• Notes or a ticketing system to document exposures and remediation owners.
• Optional scripting tools such as Python or PowerShell if you plan to use the API.

Getting Started With Shodan

Start by creating a Shodan account and learning the difference between free and paid access. The free tier is enough to learn the interface, test queries, and review a limited set of results, but premium access expands search depth, history, and automation options. The official Shodan site documents current account features and API access.

The next thing to find is your API key. That key lets you automate searches, integrate lookups into scripts, and track exposures over time. In real operations, this is where Shodan becomes more than a search box; it becomes part of repeatable monitoring. The Shodan Developer Portal is the official reference for API usage and endpoints.

Spend time with the interface. The main search bar is where most work happens, but the device result pages and Maps view are just as useful. The result page often gives you the IP address, port, service banner, hostname, organization, and location details in one place. That combination helps you move from “interesting hit” to “likely asset owner” fast.

A clean workflow helps. Save queries that matter, add notes about what each one is looking for, and keep separate searches for different device classes. A query for a webcam fleet should not be mixed with one for industrial controllers. That keeps triage fast and keeps false positives under control.

For enterprise risk context, the NIST Cybersecurity Framework and NIST SP 800-53 both reinforce the value of asset visibility, configuration management, and continuous monitoring. Those controls map directly to the way Shodan is used in defensive programs.

Understanding The Data Shodan Provides

Metadata is the descriptive information Shodan collects about a device or exposed service, and it is the key to making sense of search results. Common fields include the IP address, port, hostname, organization, geographic location, service name, and banner. A banner is the text a service sends back when Shodan connects, and it often reveals product names, software versions, or login page titles.

That matters because a device with port 80 open is not automatically a camera. A web banner that says “AXIS Network Camera” is much more useful than a generic HTTP response. Likewise, an SSH banner with a specific firmware version can point to an outdated build or a system that should be patched.

What banners usually tell you

• Device type such as camera, printer, router, or NAS appliance.
• Software version that can be compared to vendor advisories.
• Default interface name that hints at web admin access.
• Protocol clues such as Telnet, FTP, RTSP, or Modbus.

Do not overread a single result. A banner can be stale, a service can be proxied, and a hostname can be wrong. The right approach is to treat Shodan as a prioritization tool, not a confirmation engine. That is consistent with guidance from the OWASP community, which repeatedly stresses validation and context before making risk claims.

How Do You Discover IoT Devices With Shodan?

You discover IoT devices with Shodan by combining device terms, port filters, and vendor clues to narrow results to likely matches. The first pass should be broad enough to surface patterns, and the second pass should be specific enough to cut through noise. That is the fastest way to discover IoT at scale without drowning in irrelevant results.

1. Start with a broad device keyword. Search for terms like camera, webcam, printer, router, or SCADA. A broad search helps you see how Shodan labels devices in the wild and which terms return the most relevant banners.
2. Add a port filter. If you are looking for remote admin interfaces, try port:23 for Telnet, port:21 for FTP, port:80 for web UIs, or port:554 for RTSP streams. Port filters reduce noise and help isolate services commonly used by IoT gear.
3. Add a product or brand filter. Use product: or a vendor name like Cisco to find specific families of hardware. This is useful when you know the environment or want to compare what is exposed versus what should be exposed.
4. Review the first page of results before refining further. Look at banners, hostnames, and organization names to decide whether the query is finding the right class of device. The first few hits often reveal better search terms than the original query.
5. Save the query and build a baseline. Repeat the same search later to track changes, exposed assets, or newly appearing hosts. This turns Shodan into a monitoring tool instead of a one-time lookup.

Example searches can be simple and effective. A query like camera port:554 may return RTSP-enabled cameras, while router port:23 may surface network gear with Telnet enabled. If you are researching how to find open cameras on Shodan or how to find webcams on Shodan, the winning move is usually to mix device wording with service ports and then verify with banners.

People often search for como usar shodan para ver cámaras or ask about a free Shodan API key because they want a fast starting point. The practical answer is the same: create an account, learn the filters, and validate each result against the service metadata before you draw conclusions.

Using Shodan Filters To Narrow Results

Filters are what turn Shodan from a novelty into a precision tool. Without filters, a search for a common term can return thousands of unrelated hosts. With filters, you can isolate likely assets, reduce false positives, and focus on the devices that matter most.

Filter	What it Helps You Do
country:	Limit results to a specific country for regional exposure review.
city:	Zoom in on a metro area, office location, or branch region.
org:	Group results by organization name to identify owned assets.
hostname:	Target hosts with naming patterns that suggest a device class or business unit.
product:	Find services identified by Shodan as a specific product or platform.

Use country: and city: when you are checking a geographic footprint, such as offices, plants, or public facilities. Use org: when you want to see what Shodan associates with a specific organization name. Use hostname: when internal naming patterns are consistent enough to reveal the device role, such as cam, router, or kiosk.

Filters are also useful for research on a large population of devices. If you are studying exposure trends across routers or cameras, product: can tell you which vendors appear most often. If you are reviewing your own organization, org: and hostname: help separate your assets from random internet noise.

For security teams aligning to CIS Critical Security Controls, filters support Control 1 and Control 2 style activities around asset inventory and software visibility. They also reinforce the idea in ISO/IEC 27001 that knowing what you have is the starting point for controlling risk.

Finding Specific Types Of IoT Devices

Different device classes leave different fingerprints. A webcam does not look like a router, and a building controller does not look like a smart TV. The trick is to search for the software and protocol clues that each class tends to expose.

Webcams and security cameras

For cameras, start with keywords like camera, webcam, or RTSP and combine them with common ports such as 554, 80, or 8080. Many cameras expose web admin pages or live-stream endpoints, and Shodan banners often reveal vendor names or model families. When you are trying to discover IoT cameras specifically, a query like camera port:554 is a useful starting point.

Routers and firewalls

Routers and firewalls are often easier to identify by brand name, management port, or login banner. Search for vendor terms like Cisco, then narrow by ports such as 443, 80, 8443, 22, or 23 depending on the service. You are often looking for exposed admin portals, outdated firmware strings, or remote access services that should have been restricted.

Industrial control systems and SCADA

Industrial systems often expose protocol names and service descriptors that are distinctive once you know what to look for. Queries with SCADA, Modbus, or industrial protocol names can surface PLCs, HMIs, or exposed control interfaces. This is sensitive territory, so the goal is to identify and report exposure, not interact with live control systems.

Smart home and consumer devices

Smart TVs, doorbells, thermostats, and home hubs are often easier to find by vendor or ecosystem name than by generic device wording. Many of these products expose web services, cloud-facing APIs, or local discovery endpoints. Searching by product family and reviewing the banner is usually more effective than guessing the exact device type.

The same pattern works for printers, NAS devices, media servers, and office appliances. Start broad, identify the service fingerprint, then refine the search. That is the simplest way to build a reliable device-discovery workflow.

For industrial and embedded-device context, the CISA Industrial Control Systems site is a strong reference point, and NIST guidance helps anchor defensive handling of these systems.

How Do You Identify Exposed Services And Vulnerabilities?

You identify exposed services by looking at the port, banner, and version information Shodan returns, then comparing that data to known risk patterns and vendor advisories. A service on port 23 is a classic Telnet exposure. A service banner that reports an old firmware version may point to a device that needs patching or retirement.

Risky services show up often in Shodan because they are easy to recognize. FTP, Telnet, VNC, RDP, and remote admin panels are the common offenders. Some are legitimate in a locked-down environment, but they become a problem when they are reachable from the public internet without strong authentication or access control.

• Telnet often indicates legacy remote management that should be replaced or restricted.
• FTP may expose cleartext credentials or outdated file transfer workflows.
• VNC can reveal remote desktop services that should be internal only.
• RTSP may point to live camera feeds if access controls are weak.
• Web admin ports often expose login pages that should never be public.

When vulnerability-related fields appear, treat them as clues, not proof. Shodan can surface matches tied to public advisories, but that does not mean the exact host is exploitable in your context. The right next step is validation against your own asset records, patch status, and change history.

This is where defensive practice matters. Use the results to patch, segment, disable, or firewall the service. If you work under a formal program, map the findings to controls in CISA’s Known Exploited Vulnerabilities Catalog and your internal risk register.

Reading And Prioritizing Search Results

Not every result deserves the same amount of attention. The first job is deciding whether the host is relevant, current, and operational. The second job is deciding whether the exposure is high risk, medium risk, or just an artifact from an old scan.

Look for ownership clues first. Organization names, hostnames, ASNs, and geolocation data help you understand whether the device belongs to your enterprise, a vendor, a cloud provider, or a random third party. If the naming pattern matches a branch office or business unit, the result is likely worth a closer look.

How to triage fast

1. Check the exposed service first. Management portals, remote shell services, and camera feeds are top priority.
2. Confirm the result matches your asset scope. Hostnames and org fields should line up with what you expect.
3. Review the banner for freshness. Newer banners are more useful than stale, generic, or incomplete ones.
4. Separate real devices from noise. Test systems, proxies, and stale scans can all create misleading hits.
5. Document the finding. Record the IP, port, service, and action needed for remediation.

The U.S. Department of Homeland Security and workforce-aligned guidance from NICE both support a disciplined triage mindset: identify, prioritize, and act. That is the workflow you want here.

If you are building exposure review skills for a pentest role, this is a good place to practice writing plain-language findings. A good finding says what was exposed, why it matters, and what should happen next. That is exactly the kind of reporting discipline hiring managers look for.

Using Shodan Maps And Geographic Context

Maps is Shodan’s geographic view of indexed results, and it helps you spot clusters of exposed devices by location. That can be useful when you are assessing branch offices, regional infrastructure, retail footprints, or multi-site operations. A map can show patterns that a long result list hides.

Geographic context matters because exposure often follows deployment patterns. One office may have several exposed cameras because the local installer reused default settings. A plant may have multiple exposed controllers because the network design was never segmented correctly. A map can make those patterns visible quickly.

Use location data carefully. Shodan geolocation is useful for triage, but it is not a substitute for an internal asset inventory or a site survey. Before you report a location-based issue, verify it against known infrastructure, VPN endpoints, or hosting providers.

For reporting, geography helps you explain impact. If you find the same exposure across multiple regions, that suggests a systemic control failure rather than a one-off mistake. That is the kind of pattern security leaders care about because it changes remediation priority.

The National Geospatial-Intelligence Agency is not a Shodan reference, but its public posture is a good reminder that location data can be sensitive and should be interpreted with care. In practice, the right use of Maps is to support defensive analysis, not to assume location equals certainty.

How Does The Shodan API Support Automation?

The Shodan API lets you automate searches, pull results into scripts, and monitor assets over time. That makes it valuable for recurring exposure checks, alerting on newly discovered services, and integrating discovery data into internal workflows. If you already use SIEM or asset management tooling, the API can feed those systems with repeatable lookups.

A simple use case is scheduled checking of known IP ranges. Another is alerting when a query returns a new camera, router, or exposed management interface. A third is trend tracking, where you compare results from week to week and watch for new devices, changed banners, or disappearing services.

A practical workflow often looks like this:

shodan search "camera port:554" --limit 10
shodan host 8.8.8.8

That does not require you to build a huge system on day one. Start with one reliable query, one inventory source, and one reporting output. Then expand once you know the query is clean and the results are useful.

If you are working in a defensive operations role, automation helps reduce manual drift. The SANS Institute and NIST guidance both support repeatable monitoring and consistent validation as part of mature security operations. The point is not to collect more data than you need. The point is to collect the same data consistently so you can spot change.

Best Practices For Safe And Responsible Use

Use Shodan for authorized assessment, research, and defensive monitoring. That sounds obvious, but it matters because internet-visible devices can belong to your company, a customer, a hospital, a school, or a private individual. The safest posture is to keep your work passive unless you have explicit permission to go further.

Do not probe live devices just because Shodan found them. Passive identification is enough for most exposure review tasks. If you need to confirm a vulnerability, do it inside an approved testing scope with the right rules of engagement. That separation protects you legally and ethically.

Good documentation makes responsible use easier. Every finding should include the query used, the date, the host, the service, and the reason the result matters. If you are reporting to an operations or remediation team, write in terms they can act on: asset, exposure, impact, and next step.

• Keep queries scoped to your organization or approved research target.
• Avoid interactive testing unless it is explicitly authorized.
• Store evidence securely if the results contain sensitive details.
• Use responsible disclosure when you discover exposed third-party devices.

For policy and legal framing, the Federal Trade Commission and your internal governance documents are worth reviewing if you handle customer-facing or public exposure data. The rule is simple: discover first, verify within scope, and disclose responsibly.

Common Mistakes To Avoid When Searching Shodan

The most common mistake is using a query that is too broad. A search for camera without filters can return everything from webcams to industrial vision systems to text that merely mentions cameras in a banner. That wastes time and creates confusion.

Another mistake is relying on only a brand name. Brand-only searches can miss devices that were rebranded, proxied, or identified by a different service banner. Combining brand terms with ports and product filters usually gives better results.

Do not assume every result is vulnerable. Some exposed services are intentionally public and hardened. Others are stale records from a scan that no longer reflects the current state. Shodan is good at visibility, but visibility is not the same as confirmation.

Be careful with stale data. Devices move, IPs change, and banners evolve. If a result matters, compare it against your own inventory or current network controls before you report it as active. That is especially important in large environments where the same public IP can be reused.

Finally, do not confuse discovery with authorization. Finding something on Shodan does not grant permission to test it. Treat the result as a lead, not a green light.

That mindset aligns with the defensive focus of BLS computer and information technology occupations, where incident prevention and exposure reduction are part of the broader operations skill set employers expect.

Practical Workflow For Discovering IoT Devices

A good workflow starts broad, then gets narrower in controlled steps. That keeps you from getting stuck on one query and helps you build a reusable method for discover IoT work. If you do this well, you will spend less time hunting and more time making decisions.

1. Map the device category. Start with a broad term like camera, router, or SCADA to see the exposed population.
2. Refine with service filters. Add port:, product:, hostname:, or org: to remove unrelated hits.
3. Read the banner and metadata. Confirm what the service appears to be, and note version or vendor clues.
4. Rank the risk. Put management interfaces, remote access services, and legacy protocols first.
5. Record the evidence. Save the query, host, port, and notes so you can revisit the result later.
6. Repeat on a schedule. Re-run the same queries to track change, exposure drift, and remediation progress.

This is also where the CompTIA Pentest+ Course (PTO-003) | Online Penetration Testing Certification Training fits naturally. The workflow mirrors real assessment habits: enumerate, validate, prioritize, and report. Those are the habits that matter when the goal is trusted security reporting.

If you want a memorable rule, use this one: broad enough to find the device, specific enough to trust the result. That balance is what separates useful exposure discovery from random searching.

Conclusion

Shodan is one of the most practical tools for discovering internet-exposed IoT devices, especially when you need to find cameras, routers, industrial systems, and smart devices without guessing. The real value comes from combining search terms, filters, metadata, and repeatable review into a disciplined workflow.

Used correctly, it helps you expose forgotten assets, spot risky services, and build better remediation priorities. That is useful whether you are doing defensive research, asset review, or preparing for penetration testing work. If you are building those skills, the CompTIA Pentest+ Course (PTO-003) | Online Penetration Testing Certification Training is a natural match for this kind of methodical discovery.

Use Shodan responsibly, keep your searches within authorization, and turn what you find into action: patch, segment, restrict, or retire the exposed service. That is how discovery becomes security improvement.

Shodan® is a registered trademark of Shodan.