The questions we get during the first working session.

Yes. The platform is identical. The difference between vertical pages is framing for the audience and operational shape. The technical method (read-only SNMP, Layer-1 fingerprint, 750-million-device reference library) is the same in every deployment.

We identify every device on every managed switch port at Layer 1, against a 750-million-device reference library. The output is a continuous, evidence-grade device inventory. The institution's IT team uses it to keep the asset register honest. The security team uses it for audit and compliance evidence.

We are not an MDM, not a NAC, not an EDR, not a SIEM, not a firewall, not a DLP. We feed device-identity data into the products that play those roles. The About page covers the boundary in detail.

No, because we do not see FERPA-protected data. Our scope is the network layer underneath the systems that hold student records. The FERPA article walks through the analysis in detail.

No. We see that a chromebook is on a port. We do not see whose chromebook it is, what they are doing on it, or any data on the device. The student-to-device mapping lives in your identity-management system; we do not connect to that system.

No. COPPA applies to operators that collect personal information from children under 13. We do not collect personal information about students. Same scope point as FERPA: we look at network metadata, not at student data.

Most institutions ask for one anyway as a matter of process. We sign data-sharing language that accurately reflects what we do (no access to student data, no PII processing). We do not sign overstated language that implies we have access we do not have. The privacy officer reviews and signs in the normal vendor-management workflow.

For a typical K-12 district or mid-size university: roughly four weeks from credentials handoff to first signed inventory export. Week 1 is readiness (host VM provisioned, SNMP credentials prepared). Week 2 is install and first identifications. Month 1 is policy baselining and first Section 889 sweep. Month 2 produces the first signed audit-grade inventory.

No. CybrIQ reads switch metadata via SNMP with read-only credentials. We do not capture traffic, do not require a SPAN port, and do not put inline equipment in the network path.

No. We do not place agents on devices. The identification work happens at the switch layer.

A small Linux VM. We provide the spec sheet during the working session. Most institutions run it on existing IT virtualization infrastructure. We do not require dedicated hardware.

No. SNMP read traffic is light (small polling intervals, low byte volume). We do not push enforcement actions to switches. We do not modify switch configuration.

We are accessible through several state and cooperative arrangements (NASPO, OMNIA Partners, Sourcewell, TIPS, multiple state-level contracts). The procurement office can verify availability through the cooperative's contract-search tool. If your preferred contract is not yet in place, the working session is the right time to flag it; we add coverage where the volume justifies it.

Yes. The most common pilot shape is one building or one department for 60 to 90 days, with a clear go/no-go criterion at the end (e.g., "did the inventory close the gap the IT director hoped it would close"). The pilot pricing is structured so the financial commitment matches the scope.

License is per managed switch (or, for very large institutions, by tier). For most K-12 districts and most mid-size universities, the per-switch model lands cleanly under E-Rate Category 2 budget envelopes. The working session is the right place to scope the actual number.

The asset-management controls in NIST 800-53 (CM-8 family), NIST 800-171, NIST CSF 2.0 (ID.AM-1, ID.AM-2), CIS Critical Security Controls 1 and 2, K12 SIX Essentials, CMMC Level 2/3, NDAA Section 889, FISMA, SOC 2 Type II, and ISO 27001. The signed monthly export attaches to the work paper for each.

Not currently. Our position is documented under "In Process" with an agency-sponsored path under evaluation; we are happy to share the current state during the working session. For institutions that require FedRAMP-authorized cloud, the on-premise main-instance option is the right deployment shape.

On the first of each month, the main instance generates a controls-mapped inventory in three formats: PDF (forwardable, signed cover letter), CSV (raw inventory rows for the auditor), and JSON (machine-readable, with SHA-256 integrity hash). The institution receives the export by email or by direct API pull, whichever the IT team prefers.

Yes, in the sense that we coexist cleanly. The MDM (Google Admin, Jamf, Mosyle, Intune, Lightspeed, GoGuardian, etc.) does device-side management on enrolled endpoints. We tell you about everything on the network, including the devices the MDM does not see. The two operate in parallel.

Yes. We integrate with Cisco ISE (pxGrid), Forescout, and Aruba ClearPass. We feed identity events into the NAC's policy decision. We do not enforce policy ourselves.

Yes. Splunk, Splunk Cloud for Government, Microsoft Sentinel, IBM QRadar, Elastic, and LogRhythm. Identity events emit in RFC 5424 syslog and JSON over HTTPS.