Next Generation 911 for the Enterprise
What it Really Means for Businesses
VLOG Edition | By Mark J. Fletcher, ENP
Most enterprise leaders still think Next Generation 911 begins at the public safety answering point.
It does not.
It begins wherever the caller’s identity, location, and communications data are created. That may be a desk telephone, a laptop soft client, a wireless handset on a hospital campus, a dormitory phone, or a cloud session being used from home.
For decades, the enterprise emergency-calling conversation was relatively contained. Can an employee dial 911? Does the call reach the correct public safety answering point? Does the dispatcher receive a callback number and an address? Does someone at the business receive a notification?
Those questions remain important. They are no longer enough.
States are deploying Emergency Services IP Networks, commonly called ESInets, and Next Generation 911 Core Services. The FCC has established a process for prepared 911 authorities to require originating service providers to deliver emergency traffic in an IP-based format. Public safety technology is being built to receive richer location, text, imagery, video, telematics, and other incident data.
That changes the enterprise’s place in the system. A business is not generally going to connect directly to an ESInet or operate NG911 Core Services. It will, however, be expected to supply accurate information into an increasingly connected public safety environment.
This is not simply a carrier upgrade or a PSAP technology refresh. It is the construction of a new public safety relationship.
NG911 Is Moving Upstream
The legacy 911 network was built around a dependable assumption: a telephone was closely associated with a physical place. A business telephone system served a building. A trunk connected that system to the local telephone network. A telephone number could be associated with an address, and the local carrier controlled much of the path to public safety.
Cloud communications broke that relationship.
A user can keep the same number while moving among an office, home, hotel, hospital wing, or temporary workspace. A centralized platform can serve facilities in several states. In that environment, a telephone number is an identity. It is not reliable proof of location.
NG911 is designed for this more dynamic world. It treats emergency communications as a standards-based exchange of signaling, media, location, policy, and incident data. The accuracy of a 911 call therefore depends on information created and maintained before the call ever reaches the carrier’s NG911 interconnection or the PSAP.
States and Carriers Are Building the New Handoff
NG911 is not arriving everywhere at once. State and regional programs differ in governance, funding, procurement, and operational maturity. Even the phrase “connected to an ESInet” does not mean that a PSAP has every end-state i3 capability or multimedia workflow in service.
Still, the direction is clear.
North Carolina transitioned its final 911 Board-funded PSAP to its statewide ESInet in February 2024. Virginia announced final deployments in a 125-center migration for October 2025. Washington operates a statewide ESInet and core-services environment. California reported in August 2026 that 23 active PSAPs had been moved to an interim statewide platform while its long-term program continued. Texas is managing a broad regional program, while Massachusetts has operated a statewide digital NG911 system since 2017.
These examples are not a national scorecard. They demonstrate that states are building the receiving side of a new interconnection model.
In July 2024, the FCC adopted a two-phase framework that takes effect after an eligible and technically prepared 911 authority submits a valid request to a covered originating service provider.
That trigger matters. The rules did not require every provider to convert every 911 call everywhere on the day the order was adopted.
Phase 1 requires covered providers to deliver 911 traffic in an IP-based Session Initiation Protocol format to designated in-state NG911 delivery points. Phase 2 advances the handoff to standards-based SIP with location embedded in the call signaling, along with a Location Information Server or equivalent capability.
The general compliance period is six months for non-rural wireline providers, nationwide wireless carriers, covered text providers, and interconnected VoIP providers. Certain smaller and rural providers generally receive twelve months.
Unless the parties agree otherwise, the originating provider is responsible for delivery to the designated NG911 delivery point. The 911 authority is responsible for the core functions beyond it. This creates a practical boundary for engineering responsibility, testing, troubleshooting, and cost allocation.
What Carriers Are Actually Building
Replacing a TDM circuit with an Ethernet connection does not create NG911. Neither does translating a legacy call into SIP at the last possible moment and calling the work complete.
Carriers must establish secure points of interconnection, normalize signaling, preserve callback and location information, build diverse paths, and develop test plans proving that calls survive failure conditions.
Phase 2 makes location more demanding. The network must be able to obtain, validate, and convey location in a standards-based form. For a cloud or nomadic service, that can require an active relationship among the device, enterprise network, communications platform, location service, and originating provider.
AT&T offers one visible example. The company reported in 2025 that its ESInet service had upgraded approximately 1,700 emergency call centers serving more than 75 million people. It has also announced picture and video messaging, automatic crash data, private cloud connectivity, and integration among PSAP applications.
Those are AT&T’s reported figures and capabilities, not a description of every state deployment. They illustrate a larger shift away from isolated emergency trunks and toward an interconnected public safety services environment.
Legacy and IP systems must coexist while communities migrate. The danger is allowing “transitional” to become permanent.
The PSAP Becomes a Data Environment
Inside the emergency communications center, the change is larger than a new phone screen.
NG911 Core Services provide the foundation for geospatial and policy-based routing, improved transfers, and interoperable exchange among public safety systems. An i3-capable call-handling environment can support multiple forms of media and incident data.
For the individual constituent, the benefits are clear. A call can be routed using more accurate location. A person who cannot safely speak can use text. Pictures, video, or vehicle crash data may improve the information available before responders arrive. Policy-based routing can preserve service when the normal PSAP is unavailable.
More information, however, is not automatically better information.
Video can improve situational awareness, but it can also create cognitive overload and expose telecommunicators to disturbing content. New media must be secured, recorded, retained, and handled as potential evidence. Interfaces must clarify what is reliable instead of burying the call beneath alerts.
The same principle applies to enterprise data. A current floor plan can be valuable. An outdated floor plan can mislead a responder. The measure of success is not how much information enters the PSAP. It is whether trusted information improves the response.
Enterprise Compliance Is the Starting Point
Kari’s Law and RAY BAUM’S Act established the current baseline for enterprise emergency calling. Covered multi-line telephone systems must support direct 911 dialing, provide appropriate notification, and convey a dispatchable location or permitted alternative.
Dispatchable location is more than a street address. It can include the suite, floor, room, or other information responders need to find the caller. The requirements reach modern IP and cloud communications systems, not only traditional premises PBXs.
Compliance is the floor.
A technically valid location can still fail if it is stale, a building has been renumbered, or a remote worker never updated an address. A cloud migration can preserve ordinary voice features while silently changing the emergency-calling path.
The value is especially clear in complex facilities. A hospital must distinguish among clinical buildings, parking structures, and remote campuses. A university may need to locate someone in a residence hall, classroom, outdoor area, or satellite campus. A corporation may need the correct building, floor, entrance, or remote workplace while notifying internal security.
The common requirement is not simply more data. It is current, validated, protected, and operationally useful data.
A New Category of Interconnectivity
Enterprise telecommunications was once dominated by the cost of distance. Voice buyers compared rates, negotiated dedicated facilities, and designed least-cost routing. That made sense because the network was circuit-centric and geography was connected to the physical path.
911 used the same architecture. CAMA trunks, selective routers, ALI databases, local boundaries, and specialized signaling created a parallel emergency network. It saved lives, but accumulated infrastructure that exists because other pieces are old.
Today, enterprise voice is an application riding on IP connectivity. The new economic question is not which carrier offers the lowest long-distance rate. It is which participants can exchange trusted emergency traffic and location across a standards-based path without forcing someone to maintain another proprietary bridge.
That relationship involves the enterprise, its communications and location providers, the 911 authority, the PSAP, and responding agencies.
Each owns part of the truth. The enterprise knows where people should be. The access network may know where a device connected. The communications platform knows the calling identity. The provider delivers the call. The 911 authority maintains routing policy. The telecommunicator decides what is actionable, and responders discover whether the data matches the physical world.
No participant can make that chain trustworthy alone.
What Enterprises Should Do Now
Enterprise leaders do not need to wait for every PSAP to reach the same level of NG911 maturity.
First, map the complete emergency-calling path from the device through the communications platform, provider, location source, routing decision, PSAP destination, and internal notification. Include fixed, remote, nomadic, and mobile users.
Second, treat dispatchable location as managed data. Assign ownership and define how records are created, validated, changed, audited, and retired. Connect telecommunications changes to facilities and personnel processes so office moves and remote-work changes do not become hidden safety defects.
Third, test behavior rather than configuration. A valid address on a dashboard is not proof that the correct PSAP receives it. Coordinate testing with public safety, verify callback and notification, exercise failure paths, and retest after major network or facilities changes.
Fourth, ask providers specific questions. How will they respond to valid FCC Phase 1 and Phase 2 requests? Where is location created and validated? What remains dependent on legacy translation? What evidence will demonstrate end-to-end readiness?
Finally, identify the retirement criteria before migration begins. Define what must be proven before old trunks, gateways, databases, or contracts can be removed.
The Question Has Changed
The first reason to modernize 911 is public safety. Accurate location can shorten the search for a caller. Better routing can reduce transfers. Resilient services can preserve access during a disaster. Trusted incident information can help telecommunicators and responders prepare.
There is also an economic opportunity. Standards-based IP interconnection can replace dedicated circuits, aging selective routers, duplicated databases, conversion gateways, and systems that fewer technicians understand every year.
These are the legacy boat anchors of emergency communications. Many were once essential. Some remain necessary during transition. None should be preserved forever simply because removing them requires coordination.
NG911 does not automatically lower cost. During migration, the old and new environments operate in parallel, and expenses can increase. The savings arrive only when the new architecture is proven and accepted and the obsolete architecture is deliberately decommissioned. A migration plan without a retirement plan is an expansion plan.
For years, the enterprise asked whether a telephone could dial 911.
The better question now is whether the entire communications chain can tell public safety who needs help, where that person is, which information can be trusted, and how the connection will survive when one component fails.
Next Generation 911 is not an invitation for businesses to become emergency communications centers. It is an obligation to become reliable partners in the creation and delivery of emergency information.
Done well, this transition will save lives, strengthen continuity, and make emergency communications more affordable to operate. Done halfway, it will leave us supporting a modern IP system chained to the legacy infrastructure it was supposed to replace.
The promise of NG911 will be realized when every participant can exchange trusted information across a resilient, standards-based path, and when we finally have the discipline to cut loose the legacy boat anchors holding the system in place.
Sources and Further Reading
1. FCC Report and Order FCC 24-78 on facilitating NG911 implementation
2. National 911 Program overview of Next Generation 911
3. National 911 Program resources for Kari’s Law and RAY BAUM’S Act
4. NENA Baseline Next Generation 911 Description
5. NENA i3 Standard for Next Generation 911
6. North Carolina Next Generation 911 program
7. Virginia statewide NG911 deployment announcement
8. Washington State Next Generation 911 program
9. California 911 technology and NG911 transition updates
One comment