| QUICK ANSWER: Most campuses are not genuinely E911 compliant – fewer than 25% meet Kari’s Law and RAY BAUM’s Act requirements for direct dialing, on-site notification, and room-level dispatchable location data. Cloud UC platforms like Microsoft Teams Phone, Cisco Webex Calling, and Zoom Phone do not arrive compliant out of the box. Every switch port, Wi-Fi access point, and remote endpoint must be deliberately mapped. The fastest first step is a 933 test across all device types – fixed phones, softphones, and mobile UC apps – combined with an audit of when your Emergency Response Location database was last updated. |
| < 25% of educational institutions are genuinely E911 compliant – despite 60% self-reporting that they are (industry estimates) |
Here is an uncomfortable question: if a student collapsed in a remote lecture hall right now, would your campus emergency calling infrastructure reliably get first responders to the right room – on the right floor – in under five minutes?
For many institutions, the honest answer is – probably not. Campus communication environments have become genuinely complex, layered with legacy PBX hardware, softphone clients, cloud UC platforms, and mobile devices that can all initiate a 911 call with no guarantee of transmitting an accurate, dispatchable location. The federal compliance clock has already run out.
The Regulatory Floor: Kari’s Law and RAY BAUM’s Act
Kari’s Law, in effect since February 2020, establishes two non-negotiable requirements:
- Direct 911 dialing – anyone on campus must be able to dial 911 from any connected phone with no prefix or outside-line code
- On-site notification – a designated person must receive an alert every time a 911 call is placed
Section 506 of RAY BAUM’s Act adds a second layer: every call must carry a dispatchable location – not just a street address, but floor, wing, or room data precise enough to get a responder to the scene without searching.
Non-compliance penalties: up to $10,000 per violation plus $500 per day. Yet industry estimates suggest that fewer than 20-25% of educational institutions are genuinely compliant, despite 60% self-reporting compliance.
| Feature | 🔴 KARI’S LAW | 🔵 RAY BAUM’S ACT |
| Core Focus | Access & Instant Routing | Granular Dispatch Location |
| Primary Requirement 1 | 🔓 Direct 911 Dialing Must allow dialing 911 from any campus phone without prefixes (no “9” for an outside line). | 📍 Dispatchable Location Every call must deliver a precise location to first responders, not just a base street address. |
| Primary Requirement 2 | 🚨 On-Site Notification Campus security or a designated person must receive an immediate alert the moment 911 is dialed. | 🏢 Room-Level Detail The transmitted data must include the exact floor, wing, or room number to eliminate search time. |
| The Nomadic Problem | Legacy Infrastructure Older PBX systems frequently fail to route internal notifications correctly. | Softphones & Wi-Fi Laptops and mobile UC apps must track and update location dynamically as users move. |
| ⚠️ Compliance Reality | < 25% of educational institutions are actually fully compliant with both of these acts. | 60% of campuses falsely believe they are compliant until they run a test. |
| 💥 Non-Compliance Risk | 💸 Up to $10,000 per violation | 💸 Plus $500 per day for every ongoing violation. |
Why Campuses Are Harder Than Office Buildings
A corporate office with 200 desk phones is a contained problem. A major university campus is not. The variables are significant:
- Multi-building geography – distinct street addresses per building, spanning dozens of acres, each requiring separately mapped Emergency Response Locations (ERLs)
- Mixed infrastructure – legacy PBX hardware running alongside modern cloud UC platforms, often simultaneously during a migration
- Nomadic users – staff and faculty moving across buildings, splitting time between campus and home, using softphones and mobile UC apps that don’t behave like fixed desk phones
When a 911 call originates from a traditional desk phone, the switch-port location can be pre-mapped, and the PSAP (Public Safety Answering Point) receives a precise address. But when a faculty member calls from a softphone on their laptop while sitting in a visiting researcher’s office three buildings from their registered workspace, that location data is likely stale or simply wrong.
This challenge is the nomadic device problem. Nomadic E911 solutions are designed to dynamically track user locations as they move around a campus network, updating the emergency location database in near real time. Without them, any device that is not a fixed desk phone at a known switch port is a compliance liability.
E911 Compliance by Device Type
| Requirement | Fixed Desk Phone | Softphone / Mobile UC |
| Direct 911 dialing | Standard on most PBX | Requires explicit policy config |
| On-site notification | Often pre-configured | Frequently unconfigured |
| Dispatchable location | Switch-port mapped ERL | Dynamic – requires nomadic E911 |
| Remote worker path | N/A – office only | Often sends campus main address |
| Power outage resilience | POTS fallback possible | Offline without network/power |
UCaaS Migrations Don’t Come Pre-Compliant
Microsoft Teams Phone, Cisco Webex Calling, and Zoom Phone are all actively competing for the higher education market. Each can be configured to comply with E911 requirements. The operative word is “configured.”
None of these platforms arrive campus-ready out of the box. A documented Teams Phone deployment across 172 buildings required mapping 140,000 network jacks and wireless access points to establish baseline E911 compliance – a dedicated IT project, not a default setting.
Remote and hybrid workers add another layer. When a staff member logs into Teams or Zoom Phone from home and dials 911, the PSAP may receive the campus’s main address instead of the staff member’s actual location. FCC rules for non-fixed MLTS – covering softphones, mobile apps, and any endpoint not tied to a static network port – came into effect January 6, 2022. This is not a future concern.
Native Wi-Fi calling adds another wrinkle. Wi-Fi calling is a carrier feature, not a UCaaS feature – it lets a personal cellphone route a call over a Wi-Fi network when cellular coverage is weak, and most students, faculty, and visitors already have it switched on by default. Because it operates entirely outside the UCaaS environment, campus IT typically has no visibility into it and no way to configure it as part of the migration. If a phone with Wi-Fi calling enabled dials 911 while connected to campus Wi-Fi, the carrier generally uses the registered address on file for that account rather than the caller’s real-time location on campus, unless the user has manually updated their location in the carrier’s app since arriving. That gap sits outside the UCaaS project scope entirely, but it belongs on the same E911 readiness checklist as the platform migration itself.
| PRO TIP: Test Your System Before You Need ItMost regions offer a 933 test number that simulates a 911 call without dispatching emergency services. Use it across every device type: – Fixed desk phone on campus – Softphone on campus Wi-Fi – Softphone on a home network – Mobile UC app (on and off campus) For each test, confirm the location reported in your campus security notification is accurate to the room level – not just the building. Any wrong result is an open compliance issue, not a known quirk. |
What the Right Approach Actually Looks Like
There is no single-vendor, single-click answer. But a few principles hold regardless of where a campus sits in its infrastructure journey.
1. Start with a Location Data Audit
Map your Emergency Response Locations (ERLs) for every building, floor, and wing before making any technology decision. Many campuses discover during this process that their MLTS location database has not been updated since the last PBX refresh – meaning hundreds of phones point to the wrong room or even the wrong building.
2. Treat Nomadic and Remote Endpoints as First-Class Citizens
Softphone users, remote workers, and anyone on a mobile UC app need a compliant E911 path. Solutions can handle this – but only with proactive configuration. Learn more about enterprise wireless deployment strategies that incorporate safety planning from day one.
3. Build the Internal Notification Workflow
Kari’s Law requires that someone on campus be notified the moment a 911 call is placed. Define who gets notified, how, and how quickly. A well-designed workflow means campus security can begin responding before the external PSAP dispatches units.
4. Plan for Network and Power Outages
VoIP phones, softphones, and cloud UC clients all depend on network connectivity and power. A campus network or power outage can render VoIP-based emergency calling entirely offline. A backup path – POTS lines in high-risk areas, UPS coverage for critical infrastructure – is not optional for a life-safety system.
The Enforcement Reality
The compliance gap has real consequences. According to NENA data, roughly 240 million calls are made to 911 in the US each year, with 80% or more from wireless devices. Against that volume, every institution running a non-compliant MLTS is a risk vector.
In November 2024, the FCC’s Enforcement Bureau issued a consent decree against DISH Wireless for failing to deploy required dispatchable location technology for wireless 911 calls. DISH paid a $100,000 civil penalty. State-level legislation is adding pressure too: states including New Jersey, Florida, New York, and Texas have enacted Alyssa’s Law, requiring schools to install silent panic alarms directly connected to law enforcement – layering on top of the federal baseline.
The Emerging Role of Private 5G and Cellular Voice
Private LTE and 5G networks are increasingly deployed across higher education campuses – not just for IoT and data connectivity, but for voice. As campuses extend private wireless coverage into parking structures, underground facilities, and large indoor venues where public cellular and Wi-Fi are unreliable, the question of how those networks handle emergency calling becomes pressing. The short answer: if a private wireless network permits voice calls, it inherits the same E911 obligations as any other MLTS – and the technical path to compliance is less straightforward than most system integrators anticipate.
IMS and the PBX handshake. Voice over private 5G runs over IMS (IP Multimedia Subsystem) – the same signaling framework underlying VoLTE and VoNR on commercial carrier networks. Integrating IMS-based voice with an existing campus PBX requires syncing subscriber data between the PBX and the network core (HSS/UDM) and establishing a SIP trunk between the two systems. Done correctly, this enables seamless dialing between private cellular handsets and campus desk phones. Done without E911 planning, a 911 call from a private 5G device may route to the wrong PSAP or carry no location data at all.
Location accuracy: still an open problem. Private 5G deployments on a campus typically use a single site or a small cluster of access points – not enough nodes for accurate radio triangulation – and indoor environments block GPS. The FCC mandates location accuracy within approximately 3 meters for E911 calls from mobile devices. Most single-site private 5G deployments cannot meet that standard through RF-based positioning alone. The practical bridge today is pairing the private 5G network with a Wi-Fi-based location service or a dedicated indoor positioning system (IPS) – an additional integration layer that needs to be in the project scope from day one, not retrofitted after go-live.
The regulatory trigger is simpler than expected. The E911 compliance obligation activates the moment voice is permitted on the network. A private 5G campus network deployed primarily for IoT and building automation becomes a regulated carrier under FCC rules the first time a user places or receives a voice call on it. Campuses and their integrators should treat E911 configuration as a prerequisite for enabling voice – not a post-deployment item to circle back to.
Public safety DAS enhances emergency calling in a related but distinct way. A public safety distributed antenna system (DAS) – built around a bi-directional amplifier (BDA) feeding a network of in-building antennas – boosts first-responder land-mobile radio signals inside a structure, and is governed by NFPA 1225 and International Fire Code Section 510 rather than FCC E911 rules. It exists so firefighters and police can communicate with each other once they are on scene, not so occupants can dial 911, and campuses increasingly need both systems side by side. Code guidance is explicit that Wi-Fi calling is not an acceptable substitute for a public safety DAS: it cannot meet the coverage, battery backup, or survivability requirements the fire code demands. A cellular DAS built for carrier voice and data can sometimes share cabling and antenna locations with a public safety DAS, but the two remain separately engineered, tested, and annually recertified systems.
MOCN-based neutral host solutions are also gaining ground as a way to close campus cellular dead zones. A Multi-Operator Core Network (MOCN) architecture lets a single set of radios – often built on shared CBRS spectrum – broadcast multiple carriers’ network IDs at once, so students, faculty, and visitors on AT&T, T-Mobile, Verizon, or other carriers all get native coverage without the campus installing separate infrastructure per carrier or issuing new SIM cards. Because a MOCN neutral host deployment preserves each carrier’s own network path, calls placed over it can rely on that carrier’s standard E911 handling rather than requiring the campus to build a parallel emergency-calling system. For campuses with older, dense buildings that block outdoor macro signal, this is emerging as a faster and less expensive way to extend reliable native cellular coverage – and cellular E911 – than deploying a separate DAS for every carrier.
Underlying both trends is the rising adoption of native voice calling on private 5G networks themselves. Where early private cellular deployments on campuses were built almost exclusively for data and IoT, more system integrators are now enabling native VoLTE/VoNR voice service directly on the private core, so a private 5G handset can dial and receive calls the same way it would on a public carrier network. That shift is precisely what triggers the E911 obligations described above – which means the design conversation for any new private 5G project should include emergency calling from day one, rather than treating voice as a later add-on to a network that was originally scoped for data.
For System Integrators and Campus IT Teams
If you are a system integrator working in higher education, campus-wide E911 is one of the most consistently underserved areas in your client base. Many university clients believe they are compliant, even though their last PBX refresh left softphones and remote workers completely uncovered. A proactive E911 readiness assessment positions you as a safety advisor, not just a technology vendor – and it almost always surfaces a real project.
If you are in campus IT, the action items are straightforward:
• Audit your ERL database and find out when it was last updated
• Identify every softphone and mobile UC app user and confirm their emergency location path is configured and tested
• Check that your internal 911 notification workflow reaches the right people within seconds, not minutes
• If you are mid-migration to a cloud UC platform, E911 configuration belongs in the project plan before go-live – not after
For campuses exploring how 5G and private wireless networks can improve location accuracy and emergency response capabilities, see our coverage of campus wireless innovation and AI-driven campus security deployments.
If you are a system integrator working in higher education, campus-wide E911 is one of the most consistently underserved areas in your client base – and the expansion of private 5G voice on campus is making it more complex, not less. A proactive E911 readiness assessment, covering both legacy MLTS endpoints and any private cellular voice deployments, positions you as a safety advisor rather than just a technology vendor. Most assessments surface real billable work: stale ERL databases, unconfigured notification workflows, softphone users with no compliant location path, and private 5G integrations where IMS-to-PBX handshake and indoor location accuracy have not been addressed. The 933 test is your fastest opening move – bring the results to the conversation.
If you are in campus IT, the immediate priorities are straightforward: run a 933 test across every device type on your network, audit when your ERL database was last updated, and confirm your internal 911 notification workflow reaches the right people in seconds. If you are mid-migration to a cloud UC platform, E911 configuration belongs in the project plan before go-live. And if your campus has deployed – or is planning – a private 5G network that includes voice, treat IMS-to-PBX integration and indoor location accuracy as first-order requirements, not afterthoughts. None of this demands a large budget. It demands that emergency calling be treated as the life-safety infrastructure it is.
933 Test Checklist by Device Type
| Device Type | Expected Location Delivered | Pass Criteria |
| Fixed desk phone on campus | Switch-port ERL match | Campus security alert received |
| Softphone on campus Wi-Fi | Dynamic ERL match | Campus security alert received |
| Softphone on home network | Staff home address | Campus security alert received |
| Mobile UC app (off-campus) | Device GPS/home address | External PSAP receives call |
| Cellular phone (native carrier voice, incl. public safety DAS / cellular DAS / MOCN neutral host / private 5G) | Carrier-based dispatchable location (GPS or network-based) | Correct PSAP receives call with accurate location |
Cellular phones sit alongside the UC device types above rather than replacing them. A call placed over the public macro network doesn’t touch campus MLTS infrastructure at all, so it isn’t part of this test. But once cellular voice runs through campus-controlled infrastructure – a public safety DAS, a cellular DAS, a MOCN neutral host network, or a private 5G network with voice enabled – a 933 test on that path is the only way to confirm the correct PSAP is reached with an accurate location, the same way it is for any UC endpoint.
Frequently Asked Questions
Q: Our campus has been using the same phone system for years, and we dial 911 directly. Aren’t we already compliant with Kari’s Law?
Direct 911 dialing is only one half of Kari’s Law. The second requirement – that a designated on-site person receives a notification every time a 911 call is placed – is frequently unconfigured, especially on older PBX systems. Beyond that, RAY BAUM’s Act requires every call to carry a dispatchable location: floor, wing, and room data, not just a street address. Many campuses with legacy phone systems have never mapped their ERLs to that level of precision. And if any staff or faculty use softphones, mobile UC apps, or remote work setups, those endpoints almost certainly fall outside whatever compliance your desk-phone infrastructure achieves.
Q: We’re migrating to Microsoft Teams Phone. Will E911 compliance be handled automatically during the rollout?
No. Cloud UC platforms do not arrive E911-compliant out of the box. Achieving compliance requires deliberately mapping every switch port and Wi-Fi access point to an ERL, configuring dynamic emergency calling policies, and validating addresses against PSAP databases. One documented Teams Phone campus deployment across 172 buildings required mapping 140,000 network jacks and wireless access points as a dedicated IT project – separate from the platform migration itself. Remote and hybrid workers require additional configuration: without it, a staff member calling 911 from home may send the PSAP your campus’s main address.
Q: How does private 5G or a MOCN neutral host deployment change our E911 obligations?
The moment a private wireless network – whether a dedicated private 5G core or a MOCN-based neutral host system sharing CBRS spectrum – permits voice calls, it becomes subject to the same E911 requirements as any other MLTS. For a private 5G network running native IMS-based voice, that means confirming the IMS core is properly linked to your PBX and that indoor location accuracy meets FCC benchmarks, typically by pairing the network with a Wi-Fi-based location service or a dedicated indoor positioning system. For a MOCN neutral host deployment, carriers generally handle E911 through their own standard path, but you should still confirm during testing that calls route to the correct PSAP with an accurate location – particularly in spaces like parking structures and below-grade areas, where these networks are often deployed precisely because outdoor signal doesn’t reach.
