The spreadsheet goes very quiet.

Here's the thing. Finding personal devices is the easy part, because your identity provider already knows about most of them. The hard part is turning that evidence into records you'd actually show an auditor, with a named owner, a known access path, and an honest level of confidence. Here's how one IT team did it in six steps, with two admins and two weeks.

The Question the Asset Sheet Couldn't Answer

Picture a 120-person company where a quarter of the staff are contractors. People work from the office, from home, and from cafés with questionable Wi-Fi. Two admins run IT on Microsoft 365, with Intune managing the company laptops.

Then a big customer's security questionnaire asks how many personal devices can access customer data. The deadline is two weeks away. The identity records list about two and a half times as many devices as the asset sheet.

BYOD asset discovery is the process of finding personal devices that access company systems or data, then recording who uses them, how they connect, and what they can reach. You track the access, not the ownership. For the basics of running a BYOD program, see our separate guide.

Why Personal Devices Never Reach the Asset Inventory

Most IT asset management (ITAM) records start with a purchase. IT buys a laptop, tags it, and adds it to the list. Personal devices skip that step completely. They show up through a sign-in instead, usually in one of three ways.

• A personal phone with work email. An employee adds their work account in two minutes. The phone never appears anywhere IT checks.

• A contractor's own laptop. They log in from it on day one. When the contract ends, the laptop leaves with them.

• A shared family PC. Someone opens Slack "just for a minute." Now a computer used by two people has a company login on it.

The problem isn't the tools. It's the process. Onboarding never asks, "Which device will you use?" So the IT inventory only shows what the company bought, and BYOD asset discovery has to start with sign-ins, not purchases.

How to Turn BYOD Asset Discovery Into Accountable Records: 6 Steps

Most BYOD asset discovery can run on data you already have in your identity provider and MDM. Many personal devices never touch the office network, so identity data does the heavy lifting. A network scan covers the devices that do, and our guide to IT asset discovery explains how the methods fit together.

Step 1. Decide Which Company Data Puts a Device in Scope

Start with data, not devices. A device is in scope when it can reach something that would hurt if it leaked. Think customer files, finance systems, source code, and work email.

The team listed five sensitive apps. Any personal device that signs in to one of them counts. This took one afternoon.

Watch out. Don't try to inventory every phone on guest Wi-Fi. That's a lot of work for a list nobody will use.

What you get. A short scope list of apps and data that the whole team agrees on.

Step 2. Pull Device Evidence From Identity, MDM and Network Records

This step is about collecting evidence. Export from four sources.

• Your identity provider. Pull the device list and sign-in logs from Microsoft Entra ID, Okta, or Google Workspace.

• Your MDM. In Intune, filter by ownership type. In Jamf, check devices enrolled through account-driven User Enrollment.

• Work mailboxes. List the mobile devices connected to them.

• The office network. Our free Network Scanner finds every device on your LAN, including personal phones and laptops on office Wi-Fi. Export the results as a CSV and add them to your spreadsheet.

The team ended up with about 300 device entries. The asset sheet had 118 laptops.

Some entries won't have a device name. A laptop that signs in through a browser often shows only an OS and a browser in Entra sign-in logs. Keep those rows anyway. They're real access.

Watch out. Don't rely on MDM alone. The devices you most need to find are never enrolled, so MDM can't see them. Also, don't fully trust Intune's "Personal" label. Intune marks self-enrolled devices as Personal by default, so a few company laptops may be in that list.

What you get. One raw spreadsheet with a column showing where each record came from. You'll need it in Step 4.

Step 3. Clean the List Before You Count Anything

Raw device data is messy. Clean it with four rules before you report any number.

• Merge duplicates. One phone can appear several times after a reset or an app reinstall. Match by user, model, and OS, not by name. Half your users' phones are just called "iPhone."

• Match scan results by hostname. Phones use a random MAC address on office Wi-Fi, so the MAC can't tell you it's the same device.

• Mark old devices as stale. No sign-in for 90 days means stale. Don't delete them, since you may need the history later.

• Flag shared devices. Follow up instead of guessing the owner.

Here, cleanup merged 61 duplicates, marked 52 devices as stale, and flagged 6 shared ones. That left 187 active personal devices, after about two days of work.

Watch out. Don't send the raw number to management. The first BYOD asset discovery number always looks scary. Report the cleaned one.

What you get. A clean list of active personal devices.

Step 4. Sort Every Device: Seen, Attributed or Accountable

This is the step most teams skip, and it's the one that makes BYOD asset discovery worth trusting. Sort each device by how much IT actually knows about it.

Use these three levels to label every device on your clean list.

The goal isn't to make every device Accountable. The goal is that no device with access to sensitive data stays at Seen. Auditors trust honest uncertainty more than fake completeness.

Most devices on the team's list started at Seen, including every browser-only row from Step 2. A short message to each employee and contractor ("Is this your device?") moved most of them to Attributed within three days.

Watch out. "Registered in Entra ID" doesn't mean "managed." Registered only means the device signed in. It says nothing about whether IT controls it.

What you get. Every device has a confidence level.

Step 5. Choose Control Levels Based on Data, Not Device Type

Next, decide how much control each Attributed device needs. Let the data it can reach make the call.

• Sensitive data. Use app protection (MAM, or mobile application management) or allow browser-only access.

• Everything else. Require sign-in with conditional access rules, which check things like location and device health before letting someone in.

The team started with contractors. Their devices change the most, IT knows the least about them, and they leave when the project ends. We'd start there every time.

One manager refused to put MDM on their phone. Fair enough. A one-page note explaining what IT can and can't see fixed it. Track work access only. Never collect location, personal apps, or browsing history.

Watch out. Forcing full MDM on every personal device causes pushback, and people find workarounds. The workaround is usually worse.

What you get. Every Attributed device has a control level, which moves it to Accountable.

Step 6. Build Lifecycle Triggers So Records Stay Current

A BYOD record starts going out of date the day you create it. People buy new phones, and contractor projects end. Without triggers, BYOD asset discovery becomes a one-time project that's stale by next quarter. Tie updates to moments that already happen.

• Onboarding. Add one question to the checklist, "Which device will you use?" Then create the record.

• Device change. Update the record when someone gets a new phone or laptop.

• Offboarding. Revoke access, wipe work data if the device is enrolled, and close the record with a date.

The team gives every contractor record an end date on day one, so access expires on time. That's what turns a one-time cleanup into real IT inventory tracking.

Watch out. Don't delete the record at offboarding. The closed record proves access ended. Auditors like proof. They're less fond of "we're pretty sure."

What you get. Records that update through normal work, plus a quick monthly check to move leftover Seen devices to Attributed.

What IT Can Answer Now That It Couldn't Before

The questionnaire is no longer scary. That's the practical payoff of BYOD asset discovery.

After two weeks, the team's 300 raw entries came down to 187 active personal devices. Of those, 142 were fully Accountable, 31 had a confirmed owner, and 14 were still unconfirmed and blocked from sensitive apps. The answer to the customer was short. In total, 173 personal devices can reach customer data, every one has a named owner, and 14 unconfirmed devices are blocked. It's not a perfect number. It's a defensible one.

The team can now also answer the usual follow-ups, like who owns each device, what IT actually controls, and which devices lose access when someone leaves.

This matters for security, too. Verizon's 2025 Data Breach Investigations Report looked at devices infected with password-stealing malware. Of those that held company logins, 46% weren't managed by IT. Knowing your BYOD devices won't change that number. But it shows you which of those devices could be yours.

How AssetLoom Supports Accountable BYOD Records

Most inventory management software for IT assumes the company bought the device. BYOD breaks that assumption. Identity and MDM tools give you the evidence and the controls. AssetLoom is where the inventory record lives once BYOD asset discovery has done its job.

• See what's on the office network. The free AssetLoom Network Scanner finds devices on your LAN without agents and exports the results as a CSV, ready to import into AssetLoom.

• Bring device data into one place. Import your cleaned device list as a CSV, including scan results and identity-provider exports.

• Track every device through its lifecycle. Each record has a status, so you can see which devices are active and which have been closed.

• Automate onboarding and offboarding. Workflows handle the repetitive steps, so offboarding doesn't depend on someone's memory.

Your MDM controls devices. AssetLoom keeps the inventory record of which devices exist and where they stand. It doesn't replace your MDM or wipe devices. It keeps the record that tells you which devices to act on.

Start With Evidence, End With Records You Can Defend

Personal devices were never missing from your company, only from your IT inventory. Scope by data, clean before you count, be honest about confidence, and let normal work keep records current.

Start with the free Network Scanner to see what's on your office network. Still on spreadsheets? AssetLoom offers free IT inventory management for teams under 250 assets. Accurate records are what make BYOD asset discovery worth the effort.

FAQs

1. What happens to a BYOD record when someone leaves?

Close it with a date and a note on how access was revoked. Don't delete it. The closed record proves that access ended.

2. Should personal devices be part of your ITAM inventory?

Yes, as a separate asset class. Track the owner, access scope, control level, and status. Skip cost and depreciation, since the company doesn't own the hardware.

3. Is it legal to record employees' personal devices?

Recording work access is common, but rules differ by country. Tell employees exactly what you collect and why. This isn't legal advice, so check with your legal team.

4. Why does one phone show up as several devices?

In identity records, resetting a phone or reinstalling a work app can register a new device object. On a network scan, phones often use a randomized MAC address on each Wi-Fi network. Match by user, model, and OS in identity data, and by hostname in scan results.

5. How is BYOD different from CYOD and COPE?

It comes down to ownership. With BYOD, the employee owns the device. With CYOD, employees choose from company-approved devices. With COPE, the company owns the device but allows some personal use.

We hear some version of this story every year. A new admin runs nmap -sn 10.0.0.0/8 on a Friday to "see everything." By Monday, the firewall is sluggish, security has an alert, and a payment vendor is asking why their network got probed through the VPN tunnel.

Nothing malicious happened. The scan was just too big and pointed at unchecked space.

The short answer is simple. Don't sweep the whole private space. Rule out ranges that belong to vendors, cloud peers, or containers. Map the subnets you actually use, probe gateways to find the live ones, and sweep only those.

A Private IP Isn't Always Your IP

Private only means an address can't travel across the public internet. It says nothing about who owns the network behind it.

RFC 1918 defines three private IP ranges. Most companies use pieces of all three, often without a full list of where. Here's where each private IP range usually shows up in a real company network.

The 10.x range is the one people accidentally sweep. It's huge, and it's where most internal routing lives.

Inside these ranges, some addresses are reachable from your network but belong to someone else. Rule these out before you scan anything.

• Site-to-site VPN tunnels to vendors, payment processors, or a parent company

• Cloud networks peered with a partner's account

• An MSP's management network

• Pod and service ranges on your Kubernetes clusters. These are yours, but they change by the minute and usually aren't reachable from outside the cluster.

• 100.64.0.0/10 used by carrier NAT and some mesh VPNs. It isn't RFC 1918, but people often treat it like private space.

If a probe gets routed into a vendor tunnel, you aren't scanning your network anymore. You're scanning theirs. A technical task just became a contract question, and maybe a legal one.

Overlap causes a quieter problem. Two branches that both use 192.168.1.0/24 look like one subnet from headquarters. Your scan shows one office and silently skips the other.

The Real Risk Hides in Empty Address Space

The three private ranges hold about 17.9 million IPv4 addresses. A company with 300 people might use a few dozen /24 subnets. That's a few thousand addresses, well under 1% of the space.

So a blind sweep spends almost all its effort on addresses that don't exist. And that space isn't free.

• Every probe that crosses a stateful firewall can create a session entry. An unthrottled sweep opens thousands of new sessions per second, which is enough to choke a smaller branch firewall.

• Empty addresses never reply, so a blind sweep spends most of its time listening to silence.

• A steady sweep across a /8 looks a lot like the reconnaissance that IDS and EDR tools are built to catch.

These are calculated estimates at 100 addresses per second, a polite rate for a production network.

Fifty hours is a full weekend of traffic aimed mostly at nothing.

Map Your Private Space Before Sending a Single Packet

To scan private IP range safely, start with what your network already knows. You just have to ask it in the right places. Begin with the fastest sources and work down.

• DHCP scopes. They show every user and device subnet you hand out.

• Routing tables on core switches and firewalls. If a subnet is routed, it's in there.

• Firewall address objects and VPN tunnel settings. These show what is not yours, so they become your excluded list.

• Cloud network ranges. Include any peering connections.

• Device IPs from Microsoft Intune or Jamf Pro. Useful if you already manage laptops there.

• The IT inventory spreadsheet someone stopped updating in 2022. Use it as a hint, never as the truth.

Then turn what you find into three short text files.

• ours.txt for subnets you know and can document

• unknown.txt for space that is routed, but nobody can explain

• exclude.txt for vendor tunnels, peered networks, and segments you've been told not to touch

Before you run anything, confirm the target count with a dry run, as covered in our safe network scanning practices guide. If you expect a few thousand hosts and see a few million, stop and fix the list.

Run a Gateway Census, Then Sweep Only Live Subnets

Your unknown.txt list still needs checking, but you don't need to probe every address in it. Knock on the front door of each /24 before you check every room.

Most subnets put their gateway on .1 or .254. Probe only those two addresses in each /24, and you learn which subnets are alive at a fraction of the cost.

Most scanners can run a census like this if you set four things.

• Targets. Only the .1 and .254 addresses of each /24 in your unknown list.

• Discovery only. Check whether hosts are alive, with no port scanning.

• No DNS lookups. Reverse lookups on every live host slow the scan and add load to your DNS server.

• A rate limit. Around 100 addresses per second is gentle enough for most production networks.

At that rate, a full sweep of the 10.x range checks 16,777,216 addresses and takes about 47 hours. The census checks 131,072 addresses and takes about 22 minutes. Same question, about 128 times less traffic.

A census has limits. Some gateways ignore ping, so add a TCP check on common ports like 22 or 443. The census also assumes /24 subnets. A /22 has one gateway for four /24 blocks, so three of them look empty. Compare the results with your routing table, which shows the real subnet sizes. A subnet that stays silent is unconfirmed, not empty.

Then run your normal discovery sweep on the live /24 subnets only.

Where You Scan From Changes What You Find

The same scan gives different answers depending on where it starts. On the same segment, ARP works and almost every device has to answer. Cross a router, and you only see what ping, TCP, and the firewall allow. Over VPN, split tunneling may reach only part of the network, while a full tunnel pushes scan traffic through the concentrator your remote colleagues rely on. In the cloud, scan from inside, where security groups decide what answers.

Even your own laptop can mislead you. Docker and WSL often claim 172.17.x, so probes to that range never leave your machine.

Our rule is simple. Use one scanner per site or VLAN, not one laptop at headquarters.

When Scan Results Lie

Scan results look precise, which is exactly why they fool people.

• Every address looks alive. Locally, that's usually proxy ARP. Across a router, it's often a firewall answering TCP probes for every address.

• Windows machines look offline. Windows Firewall blocks ping by default.

• Two sites merge into one list. Overlapping subnets produce duplicate IPs for different devices.

The fix is a cross-check against your DHCP and routing data. A device that shows up in only one source deserves a closer look.

Read more about how ARP, TCP and passive checks find devices that ignore ping in our guide to IT asset discovery.

How AssetLoom Supports Ongoing Device Visibility

Even a clean IP list is not an IT inventory. It tells you something is answered. It doesn't tell you what it is, who owns it, or whether anyone should care.

This is where the surprises show up. That mystery device on an undocumented subnet is often a printer a department bought on a company card and plugged in themselves. Nobody did anything wrong. It just never made it into the spreadsheet.

We built two tools that cover both halves of IT inventory tracking. The free scanner finds what's connected, and AssetLoom, our IT asset management (ITAM) platform, turns those results into records your team can act on. Here's how the workflow looks.

• Scan your approved ranges. Run the AssetLoom Free Network Scanner against the live subnets from your census. It works on Windows, macOS, and Linux, needs no agents or sign-up, and runs locally, so your network data stays with you. Start with a dry run to confirm the target count before any packet leaves your laptop.

• Export a clean list. The scanner writes one record per device, with details like IP address, MAC address, hostname, and vendor. Choose CSV for spreadsheets and imports, or JSON for scripts.

• Import your device list. Bring the CSV into AssetLoom. Each live device becomes an asset record instead of a row in a file nobody opens again.

• Assign an owner. Give every asset an owner and an assignment. When the mystery printer shows up in next quarter's scan, you already know which department to call.

• Label the hardware. Generate QR code and barcode labels so the device on the desk matches the record on screen. Your team can check devices in and out with the AssetLoom mobile app.

• Track the lifecycle. Keep each device's status and assignment in one place, from purchase to retirement.

• Compare it with your MDM. Connect Microsoft Intune or Jamf Pro to sync your managed devices. Anything in your scan that's missing from that list deserves a conversation.

The scanner finds what's connected. AssetLoom keeps it accounted for.

Final Thoughts

Safe scanning in private space comes down to order. Rule out what isn't yours, map what you use, run a gateway census, then sweep only live subnets. Most of the risk is gone before the first packet leaves your laptop.

Map your private space first, then run your sweep with the AssetLoom Free Network Scanner and import the CSV into AssetLoom. That's how you scan private IP range safely.

FAQs

1. Is it legal to scan my company's private IP range?

Scanning your own network is normal IT work, but you still need written approval. Be careful with ranges reached through vendor tunnels or peering. Those belong to someone else, and scanning them without consent can break a contract or create legal problems.

2. How long does it take to scan 10.0.0.0/8?

At 100 addresses per second, a full sweep takes about 47 hours. A gateway census that checks only .1 and .254 in each /24 takes about 22 minutes.

3. Can I scan private IP range from the internet?

No. Private addresses aren't routable on the public internet. To scan private IP range safely, run the scan from inside the network, from a scanner at each site, or over a VPN connection.

4. Can I sweep IPv6 private ranges (ULA, fd00::/8) the same way?

No. A single IPv6 /64 subnet has far too many addresses to sweep. Use neighbor discovery, DHCPv6 leases, and router tables to find IPv6 devices instead.

5. What if our private ranges overlap with a vendor's or an acquired company's network?

You can still scan private IP range safely when ranges overlap. Scan each site with a local scanner and keep the results in separate jobs. Label every result set by site, so two devices with the same IP never end up in one record.