10 Ways Schools Use Automated Security Policies

Automated security policies let IT decide in advance how to respond when a school-issued device leaves an approved area, connects to a network outside the district, or goes several days without checking in. Once the rule is set, the response runs automatically every time the condition is met.

Those situations are part of everyday device use. In CoSN’s 2025 State of EdTech District Leadership report, 66% of districts said they support off-campus broadband access, showing how much school device use still happens off campus.

The workload around those devices is already demanding. CISA identifies resource constraints as a major barrier to effective K-12 cybersecurity programs. Geofence breaches, missed check-ins, and network changes are operational device events, not proof of a cyber incident, but they can still create manual follow-up for IT. Repeatable rules give teams a consistent way to respond when those conditions occur.

In Senturo, we call these rules Security Policy Automations. Each one connects a trigger, such as a device leaving a geofence, to the actions you want to run, such as turning on Missing Mode, and applies them to the device groups and schedule you choose. 

How a Security Policy Automation Works

A Senturo Security Policy Automation has four parts: one trigger, one or more ordered actions, the device group, and the schedule during which the rule can run.

We offer four triggers: Outside Geofence, Inside Geofence, IP Fencing, and Senturo Agent Phone Home.

The walkthrough below shows those pieces in the dashboard, using an Outside Geofence automation that sets Missing Mode, tags the device, and emails IT.

‍

‍

An automation can be saved as a draft before activation. Once active, it can also be paused without rebuilding the rule.

1. Flag Devices That Leave Campus

Outside Geofence runs when a device leaves a saved boundary, such as a campus or the whole district. You set up the area once, and the automation decides what happens every time a device crosses it.

With our geofencing controls, IT can create Radius or Jurisdiction boundaries for use in Inside Geofence and Outside Geofence automations. If you need something more specific, such as a school property line or a group of locations, you can also request a custom geofence at no additional cost. For campus-only devices, the workflow might send an administrator email, request a fresh location, enable Missing Mode, or lock the device.

2. Notice When a Device Enters a Monitored Area

Inside Geofence runs when a device enters a selected boundary, which makes it useful for places where a missing device is likely to turn up. A district could draw small-radius geofences around local pawn shops or resale stores and run Set Missing Mode and Send Email to Administrator as soon as a device enters one. The same trigger also works for a missing device returning to campus, where Pull Current Location gives the team a current data point before deciding what to do next.

3. Detect Connections Outside Approved Networks

IP Fencing compares a device’s connection against approved IP ranges. A connection from outside that list can start an automation.

Pull Current Network Data and Send Email to Administrator can give IT more context. An unfamiliar network does not prove malicious activity, so the response should reflect the device group and district policy rather than treating every exception as a threat.

4. Respond When Devices Stop Checking In

Agent Phone Home uses a district-defined number of days without a Senturo check-in as the trigger condition.

That can surface unreturned loaners, forgotten spares, or devices whose agent has gone quiet. The automation can issue a Senturo Lock action when the threshold is reached. The device doesn’t have to come back online for the automation to fire, but the lock takes effect only when it reconnects, which is also when IT starts receiving fresh location data again.

5. Apply Policies Only When They Matter

Every automation includes a schedule. Our automation scheduling can keep a rule Always On or limit it to selected days, time windows, and optional date ranges.

A campus-only device leaving at 11 a.m. may call for a different response than the same movement during an approved weekend program. Each device applies the schedule in its own local time. This keeps enforcement tied to the context the district intended when it created the policy.

6. Collect Fresh Context When a Rule Fires

The first action can be informational rather than restrictive. Pull Current Location requests a fresh location reading, while Pull Current Network Data retrieves current network information.

Those actions can run before an administrator notification, giving IT more context about the device when the trigger fires. For location or network exceptions, collecting that information before applying a restriction can make the alert more useful and reduce unnecessary escalation.

7. Start a Recovery Sequence Automatically

Because actions run from top to bottom, one trigger can start several recovery steps in a defined order. A device leaving an approved area could move into Missing Mode, have its current location pulled, receive Senturo Lock, and then generate an administrator email.

Missing Mode increases check-ins to approximately every 60 seconds while the device is online. Senturo Lock restricts access on Windows, macOS, and ChromeOS devices, and the lock screen can show your contact details or a message telling the person what to do next. If the device is offline, the lock waits and applies as soon as it reconnects. Access comes back when an administrator sends Senturo Unlock. 

8. Send Instructions to the Device

Sometimes communication is more useful than restriction. Send Broadcast can display instructions on the device, such as asking the user to return it to the IT office or contact the district.

9. Keep Follow-Up Attached to the Device Record

Admin actions can add or remove a device from a group, apply or remove a tag, and add a note to the device record.

A device that leaves an approved area could be tagged for review and moved into a group with a different policy, keeping the event and next step attached to the device instead of a separate spreadsheet.

10. Use Connected MDM Actions in the Same Workflow

When the relevant integration is connected, and the target device is managed by that platform, Senturo automations can run supported MDM actions including Jamf Lock, Jamf Lost Mode, Microsoft Intune Lock, Meraki Lock, Meraki Wipe, and Google Disable.

Those commands still come from the connected MDM. Senturo supplies the trigger and workflow around them, so the existing management environment remains part of the response.

What Security Policy Automations Do Not Replace

Security Policy Automations are one control within a broader device and cybersecurity program. They do not replace web filtering, patch management, endpoint protection, identity controls, backups, MDM configuration, or incident response processes.

The NIST Cybersecurity Framework 2.0 is a useful way to see where automations fit. It organizes cybersecurity into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. Security Policy Automations mainly help with Detect and Respond for school devices. The other functions still depend on the policies, tools, and processes a district already has in place.

Platform support also matters. Before activating a high-impact workflow, confirm that every action is supported on the operating systems in the selected group and test the automation on a small device group. Unsupported actions are skipped, and MDM actions require the corresponding integration and a device managed by that platform.

For a new policy, start with a low-risk response such as an administrator notification, confirm that the trigger behaves as expected, and only then add stronger actions where the use case calls for them.

‍

‍

Frequently Asked Questions

Can a district test an automation before turning it on broadly?

Yes. You can save an automation as a draft and test high-impact workflows against a small device group before a wider rollout.

What happens if an action is not supported on a device's platform?

Senturo skips unsupported actions. Check current compatibility requirements before applying one automation across a mixed-OS group.

Can one automation combine different types of actions?

Yes. Security, admin, tracking, and supported MDM integration actions can be combined and run in the order you set.

Can the same trigger policy be reused?

Yes. A configured trigger policy can be selected by more than one automation. Because policies are shared, review other automations before editing one.

Do MDM actions require an MDM integration?

Yes. They require the corresponding platform to be connected with the necessary permissions, and the target device must be managed by that MDM.