Class Guard for network administrators
The architecture, the prerequisites, and the things it deliberately doesn't do.
What it is
Class Guard is a policy controller. It correlates RADIUS session data with class roster and schedule data, then writes time-bounded policy objects to your firewall. It is not a filter, not a proxy, and not inline with your traffic. Your firewall continues to do the filtering it does today. ClassWay changes which rules apply to which student, and when.
How it integrates
Identity. Class Guard reads session data from your existing RADIUS server to map an authenticated student to a device and IP.
Roster and schedule. Class sections and bell schedules come from LMS integration, CSV, or manual import.
Enforcement. Class Guard populates dynamic address groups on your firewall and attaches them to policies you control. Rules are scoped to a class period and expire on their own.
Supported firewalls. SonicWall and FortiGate today. Many more in the pipeline!
What you need to have
A RADIUS server handling wireless authentication for student devices
A supported firewall with its management API reachable from the controller
[[ FIRMWARE MINIMUMS ]]
[[ ANY FIREWALL LICENSE OR SUBSCRIPTION REQUIREMENTS ]]
What Class Guard does not do
Being direct about the edges, because you'll find them anyway:
It does not follow students off campus. Policy applies to sessions on your network. A district-issued laptop at home is outside its scope.
It does not control cellular traffic. A phone on LTE isn't on your network. ClassWay governs what happens on your wireless, which is where most phone traffic on campus actually goes.
It does not replace your content filter or your CIPA compliance posture. Your firewall does the filtering. Class Guard orchestrates which policy applies to whom. CIPA compliance remains a function of your filtering configuration.
It is not a monitoring or screen-visibility product. No screenshots, no browsing content capture, no alerting on student behavior.
Deployment and data
Model. Single tenant. Each school gets its own instance and its own database, matching the one-school, one-firewall, one-RADIUS topology.
Hosting. Digital Ocean Droplet, NYC
What's stored. Student identifiers from your roster source, class sections and schedules, network session bindings, policy records, and an audit trail of policy changes.
What isn't. Browsing content, screen captures, student work, or any activity outside the school network.
Retention and deletion. presence data (MAC/IP/time) is purged on a 24-hour time-to-live; roster data is deleted on request and at contract end.
Security and compliance
SOC 2. [[ IN PROGRESS. State the type and your target date. Offer the report under NDA once available. Do not imply you have it. ]]
Authentication. [[ DESCRIBE ACCURATELY. If SSO isn't available yet, say what's on the roadmap and when, rather than leaving it unaddressed. IT Directors will ask in the first meeting either way. ]]
Encryption. [[ TLS VERSION IN TRANSIT, ENCRYPTION AT REST ]]
Subprocessors. [[ PUBLISH THE FULL LIST ONCE CONFIRMED. Districts will ask, and a list that turns out to be incomplete costs more trust than no list. ]]
Agreements. We'll sign the Massachusetts Student Data Privacy Agreement and standard exhibits.