FERPA and device visibility: the boundary that matters

A 5-minute read for K-12 IT directors, university CIOs, and privacy officers.

Whenever a security vendor enters a conversation with a school district or a university, the privacy question gets asked early. It usually arrives in this shape: "If you have visibility into our network, are you a FERPA school-official-with-legitimate-educational-interest, or are you outside FERPA scope entirely?" The answer matters for the data-sharing agreement, for the institution's annual privacy notification, and for the broader question of what the institution is comfortable having on its network.

This article is the short version of the answer. We are not a FERPA school official, because we do not see the data FERPA covers. The reason is structural. Our scope ends at a layer below the systems that hold education records.

What FERPA actually protects

FERPA (the Family Educational Rights and Privacy Act, 20 U.S.C. § 1232g) protects "education records" maintained by an educational institution that receives federal funding. The Department of Education definition is specific: records, files, documents, and other materials that contain information directly related to a student and are maintained by an educational agency or institution. In practice, this includes:

• Grades, transcripts, and academic standing
• Attendance records
• IEP and 504 plan documentation
• Disciplinary records
• Health records held by the school (not by an outside provider)
• Library checkout records (in some states' interpretations)
• Correspondence between school officials about a student

What FERPA does not cover is the network metadata about how a student's device connects to the institution's network. The MAC address of a chromebook, the switch port it is plugged into, the time of day it was online: none of these are education records under any reasonable reading of the statute. They contain no information about the student's academic performance, behavior, or any of the other categories the statute names.

What CybrIQ sees

The CybrIQ scan engine reads each managed switch via SNMP with read-only credentials. The data we capture per port:

• The MAC address of the device on the port
• The link-negotiation pattern (speed, duplex, autonegotiation timing)
• LLDP and CDP advertisements when the device emits them (vendor name, model, firmware version)
• Port statistics (utilization, error rate, link history)
• VLAN context

From this, we identify the device's vendor and model. A chromebook resolves as "Acer C722 chromebook" (or whatever the actual hardware is). A smart display resolves as "Samsung Flip 65-inch" or whatever the actual model is. The MAC OUI is the largest single signal; LLDP fills in model and firmware where the device advertises.

What CybrIQ does not see

The list below is not aspirational; it is structural. We literally cannot see these things because the scan engine does not read them.

• Traffic content. We do not inspect packets. We do not know what the student is browsing, what they are typing, what they are watching, or what they are downloading. We have no visibility into application-layer activity.
• Student records. We do not connect to the SIS, the LMS, the gradebook, the library system, or the IEP system. The institution's records systems are entirely outside our scope.
• Device-side data. We do not place an agent on any device. We do not have credentials to log into student devices, faculty laptops, or any endpoint. We see what the switch reports about the device's network presence, nothing more.
• Identity correlation. We do not associate the device with a named student. The institution's identity-management system (Google, Microsoft, Clever, ClassLink, etc.) handles that mapping. We see the chromebook; we do not see whose chromebook it is.

What this means for the data-sharing agreement

The institution's data-sharing agreement (DSA), data-protection addendum (DPA), or vendor-management questionnaire usually has a section asking whether the vendor accesses, processes, or stores student personally identifiable information (PII). For CybrIQ in education, the honest answer is no. We do not access education records; we do not store student PII; we do not transmit student PII to any third party. The agreement can attest to this and the privacy officer can sign without reservation.

If your institution prefers a vendor that signs FERPA school-official terms regardless, we can do that as a posture exercise. The substantive answer does not change: we are not a FERPA school official because we do not see the records FERPA protects. The signing is precautionary, not necessary.

A note for higher education specifically

The same analysis holds for higher-education institutions, with two additions worth naming:

• HIPAA in academic medical centers. If the institution operates a hospital or clinic, the medical-side network handles PHI. CybrIQ in a medical-center context follows our healthcare-vertical posture (the same analysis: we see network metadata, not PHI). The healthcare vertical page covers this in detail.
• Research-side regulated data. Federally funded research environments handle Controlled Unclassified Information (CUI), Restricted Data (RD), or other regulated categories. CybrIQ does not touch any of it. Our scope is the network-layer device identification, not the research data the institution stores.