How to Detect School Devices on Unapproved Networks

District IT teams usually know which public IP ranges belong to their schools. The harder question is what to do when a school-issued device reports a connection from somewhere else. That may be ordinary activity for a take-home laptop, or a reason to investigate equipment assigned to a classroom.

NIST recommends securing organization-issued devices that are used from external locations, and for district IT, that starts with knowing when a device connects from outside your networks. Detecting school devices on unapproved networks is most useful when IT can read the reported IP address alongside the device's assignment and last check-in.

What Counts as an Unapproved Network?

In an IP Fencing policy, unapproved has a specific meaning: the device reported an IP address outside the ranges your district has chosen to trust. Those ranges might include school buildings, administrative offices, and other district sites. Home Wi-Fi and public networks will normally fall outside the list unless you have deliberately added them.

The NSA's public Wi-Fi guidance covers precautions for devices used in public settings. An unfamiliar IP address alone doesn't show that a device has been compromised. Before deciding how to respond, check whether its user had a reason to connect outside the district's networks.

How Do Districts Define Approved IP Ranges?

You enter approved ranges in CIDR notation, the format described in RFC 4632. A range like 203.0.113.0/24 covers 256 addresses, and 203.0.113.25/32 is a single address on its own.

Get the ranges from your network team or internet provider instead of relying on an old list. A school's public address can change when it switches providers or adds a circuit, and if nobody updates the whitelist, devices sitting on campus will start triggering the automation.

How Our IP Fencing Trigger Works

IP Fencing is one of the triggers in our Security Policy Automations. We compare the IP address a device reports against the ranges in your Whitelisted IPs policy. If the address falls outside all of them, the trigger condition is met, and the device groups, schedule, and actions you set up decide what happens after that.

You build the whitelist using our CSV template, with each approved range on its own row. After you upload it, several automations can use the same policy. That helps districts with multiple sites maintain one list, although any change to the shared policy affects every automation attached to it.

With IP Fencing, we only check that address. We do not inspect traffic, filter websites, or block a device from connecting through this feature, and your existing network security tools continue to handle those protections.

‍

Use the walkthrough to set up your approved IP ranges and choose the actions, device groups, and schedule. Review the affected devices before saving and activating.

Choose Device Groups and Set the Schedule

Take-home laptops will regularly connect to home Wi-Fi. Giving them the same rule as devices that stay in a testing cart would fill your inbox with expected connections, making it harder to notice equipment that shouldn't be off the school network.

Campus-based equipment, such as shared classroom devices, is a reasonable place to start when you know its normal network. Student and staff take-home laptops often need a different policy.

Our Custom Schedule lets you limit when the policy runs. You can start with the School Hours preset, choose specific days and times, or limit a policy to dates such as an exam period. We apply the schedule in each device's local time, so the hours you select should match how that group actually operates.

Even on a school day, some devices need to work off campus. Check with the school about field trips and staff working elsewhere before adding a lock action. You can review the selected devices through Preview affected devices in our automation builder. Use Save as Draft while a colleague checks the setup.

Decide How the Automation Responds

An IP address alone gives an administrator very little to act on. We run actions in the order you select them, so an automation can pull current network and location information first and only then send the email.

‍

‍

For a first deployment, consider limiting the automation actions to pulling network data and location, then emailing the administrator, and let those results guide any further response.

If a device should never leave an approved network, Senturo Lock may be appropriate, but check our platform compatibility information before adding it.

Investigate the Connection After an Alert

The last logged-in user may help explain an unexpected connection. In the device record, compare that user with the device's assignment and look at the reported network and available location. Make sure the update is recent enough to be useful. Devices using the same home router, coffee shop, or hotel network can share one public IP, so a matching address won't tell you who has the device.

Our search keywords can help you compare devices. Use ip: for a last-known IP address and wifi: for the last reported Wi-Fi network. A search for ip:203.0.113.25, for example, returns devices that last reported that address, although it does not show what they did while connected.

An offline device's record shows what it last reported, which can still help you work out what happened. We won't receive another update until it reconnects, so check the date before treating that location as current.

The Automations list shows a live non-compliant count of devices that currently meet the trigger condition. If you need to review an earlier incident or activity over several days, use the device records and available reports instead. The live count only shows what is happening right now.

Test the Policy Before Expanding It

During the first run, keep the automation to one familiar group and go through the alerts with its school contact. Are they pointing to connections that need a follow-up? Sort out any missing school IP ranges or active hours that don't fit the group's use before adding more devices. Make sure the emails reach the person responsible for following up.

Give the whitelist an owner, too. That person keeps it in step with the network team and checks which automations use the policy before changing it.

Then look at access. Decide who on your team needs to see network and location details and, separately, who should be allowed to lock a device. Our privacy controls include role-based access and location-visibility settings. You are still responsible for applying your own privacy and compliance policies.

‍

‍

Frequently Asked Questions

Can I combine IP Fencing and geofencing in one automation?

Our builder uses one trigger per automation. You can use IP Fencing and geofencing for the same device group by creating a separate automation for each. Each rule then runs when its own condition is met.

What does "network CIDR not set" mean?

The IP Fencing trigger does not have approved IP ranges attached. Select an existing Whitelisted IPs policy, or create one using our CSV template, and check that it contains the ranges you intend to use.

Can I use an MDM lock action instead of Senturo Lock?

Yes, on supported devices. If your district has connected Jamf Pro or Microsoft Intune with the required permissions, you can choose the corresponding MDM action. These actions run through the connected MDM; our Senturo Lock action uses the device agent.

What if an action is not supported on a device?

We skip an action that the device's operating system does not support. Check the compatibility information before activating an automation that includes different platforms, particularly when the response involves locking a device.