Does Kari's Law apply to my phone system?

By Michael Obraitis, Managing Partner, and Michael Dale, CEO · Published August 17, 2026 · Last reviewed August 2026 · ADAM Pulse Knowledge Base · Emergency Calling Series

Short answer

If your organization operates a multi-line telephone system, Kari's Law probably applies, and the deciding factor is when the system was manufactured, imported, first sold or leased, or installed — not how big your company is or who sells you the service.

For covered systems, the federal rules require two things:

1. Direct 911 dialing. A user dials 911 and nothing else. No 9 first, no access code, no prefix.
2. Notification. The system alerts a central location on site, or another person or organization, where someone is likely to see or hear it — where the system can be configured to do this without a hardware or software improvement. The notice must say that a 911 call has been made; a callback number and the caller's location go with it unless that is technically infeasible.

Kari's Law is often confused with Section 506 of RAY BAUM's Act. They are separate requirements with separate deadlines. Kari's Law is about reaching 911. RAY BAUM's Act is about responders finding you once you do.

You can keep 9 + 911 working as well. The rule is that 911 on its own must reach emergency services without a prefix; it does not forbid a system from also accepting other dialling patterns. Supporting both is usually the right answer, because it covers the people who have been trained for years to dial 9 first.

Why this law exists

Kari Hunt was killed in a hotel room in Marshall, Texas in December 2013. Her nine-year-old daughter tried to call 911 four times and never reached it, because the hotel's phone system required a 9 before an outside line and she had no way to know that.

That is the whole of the prefix rule. Everything below — the dates, the definitions, the notification mechanics — exists because a child dialled the number she had been taught and nothing happened.

It is worth keeping in view when this reads like an administrative exercise. The requirement is not that the system be configured correctly. It is that a person in the worst moment of their life, who has never seen your phone system before, can dial three digits and be heard.

The dates that decide it

This is the part most summaries leave out, and it is the part that determines whether you are already late.

Note the last column. The two 2022 rows look identical and are not. An on-premises non-fixed device falls back to alternative location information; an off-premises device falls back to enhanced location information, which may be coordinate-based. If you are designing for a hybrid workforce, that distinction is the whole design.

On citing these dates. The rules were adopted in FCC Report and Order 19-76 (1 August 2019, published at 84 FR 66716), but the January 2021 and January 2022 compliance dates are not in that order — they were left pending OMB approval and announced later, at 85 FR 78018 (3 December 2020). Cite the Federal Register notice for the dates and 19-76 for the rules. Anyone who checks 19-76 for the dates will not find them.

Two practical consequences. First, if you are reading this in 2026 and have not looked at your emergency calling configuration, every one of these dates is behind you. Second, "fixed" versus "non-fixed" is doing real work: a desk phone bolted to a desk and a softphone on a laptop sit on different deadlines with different obligations.

One more trigger worth reading carefully. Section 9.15 applies subpart F to systems "manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020" — after, not on or after. And § 9.17 sets the compliance date for the whole of subpart F at 16 February 2020 "unless otherwise noted", which is what the dispatchable location dates above are.

Kari's Law and RAY BAUM's Act, side by side

A complete emergency calling design has to satisfy both. Satisfying one is not evidence of the other.

What "dispatchable location" actually says

The regulatory definition is worth quoting rather than paraphrasing, because two words in it are routinely dropped. From 47 CFR § 9.3:

"Dispatchable location. A location delivered to the PSAP with a 911 call that consists of the validated street address of the calling party, plus additional information such as suite, apartment or similar information necessary to adequately identify the location of the calling party, except for Commercial Mobile Radio Service providers, which shall convey the location information required by subpart C of this part."

"Validated" makes this a data-quality obligation. An address that is correctly formatted, plausible and wrong does not satisfy it. Most summaries drop the word and turn the rule into a formatting exercise.

The CMRS carve-out matters if your workforce is mobile-heavy. Commercial Mobile Radio Service providers are governed by subpart C instead. Summaries that omit this tell readers a rule applies to them that does not.

What counts as a multi-line telephone system?

An MLTS is a telephone system serving multiple users or extensions. That covers the obvious cases — offices, hotels, schools, hospitals, government facilities, campuses, warehouses, retail chains — and it covers cloud platforms too.

Two assumptions worth killing:

"We moved to the cloud, so this is the vendor's problem." Moving from an on-premises PBX to a cloud platform does not transfer the obligation. It changes who configures what, not who is responsible for the outcome.

"We're too small for this." Company size is not the test. A ten-person office with a multi-extension phone system is operating an MLTS. The test is the system and its deployment history.

Is my old phone system grandfathered?

The word "grandfathered" is doing a lot of unearned work in most conversations about this.

Kari's Law attaches to systems manufactured, imported, offered for first sale or lease, first sold or leased, or installed after 16 February 2020. A PBX that has sat untouched since 2015 is in a different position from the same PBX after you added a new site, swapped the hardware, or migrated the platform.

So before anyone says "grandfathered", document:

• Original installation date
• Major replacements and hardware changes
• New site installations
• Platform or cloud migrations
• New PBX deployments

If the system was replaced or newly installed after the applicable date, the analysis is different. And if the answer actually affects your compliance position, that is a question for counsel, not for a vendor's blog post.

What the notification requirement actually says

Most summaries stop at "notify someone". The rule is more specific than that, and the extra detail is where deployments fail.

The requirements sit in two places, and they carry two different feasibility qualifiers. Getting them the wrong way round is easy.

What the notice must contain — from the definition of "MLTS notification" at 47 CFR § 9.3, it must include at a minimum:

1. The fact that a 911 call has been made. No exception. This element is mandatory.
2. A valid callback number.
3. The caller's location information as conveyed to the PSAP.

Elements 2 and 3 carry the escape clause: "the notification does not have to include a callback number or location information if it is technically infeasible to provide this information." Element 1 does not. A system that cannot tell anyone a 911 call happened does not have a technical-infeasibility defence.

How it must behave — from 47 CFR § 9.16(b)(2), the notification must be:

• initiated contemporaneously with the 911 call, "provided that it is technically feasible to do so"
• must not delay the call to 911
• sent to a location where someone is likely to see or hear it

Note that the feasibility qualifier here attaches to timing, not to content. These are separate carve-outs in separate rules and they are not interchangeable.

The whole obligation applies where the system can be configured to provide the notification without an improvement to its hardware or software.

A practical read: a nightly email digest of 911 calls fails on contemporaneity. A notification that fires correctly but says only "alarm" fails on element 1.

Note what the FCC did not require: the notification point does not have to be staffed or monitored around the clock. The standard is "likely to be seen or heard", which is a question about how your building actually operates at 2am, not a question about your org chart.

Does it apply to Zoom Phone?

Kari's Law applies to systems and circumstances, not to named vendors. Zoom Phone is an MLTS environment, so the analysis is the same one you would run on any platform.

Zoom provides the capability. You own the configuration. Specifically, Zoom Phone supports emergency addresses, emergency call routing, internal safety response teams, company locations and sublocations, and nomadic emergency services that detect a user's location from network data. None of that configures itself, and none of it stays accurate on its own as people move desks, open offices and change networks.

Three Zoom-specific facts worth knowing before you plan a deployment, each confirmed in Zoom's own documentation:

Location detection is a hierarchy, not a single signal. Zoom works down through network switch MAC address and port, wireless access point BSSID, private and public IP data, personal location data, and GPS on capable US and Canadian devices.

There is a fallback, and it is not a strategy. Where a US or Canadian user's network matches no defined location, Zoom reports their confirmed default emergency address. If the user has never selected, created or confirmed one, the location is reported as unknown, which routes the call through a nationwide emergency services clearinghouse. That is a safety net for the unforeseen, not a substitute for maintaining location data.

The mobile app is outside all of this. Zoom's documentation is explicit: "The Zoom mobile app doesn't use nomadic emergency services. The app always uses the phone's native carrier when making an emergency call." If your emergency calling documentation does not distinguish between desktop, desk phone and mobile, it is wrong.

Callback needs a number that can be called back. A user with an extension and no direct number has nothing for a PSAP to ring if the call drops. Zoom's emergency number pools exist for that case — a set of numbers the platform can present as the callback path for extension-only users. If any part of your estate is extension-only, this is the setting that decides whether a dropped emergency call can be re-established.

Where deployments usually fail

In rough order of how often they show up:

1. An outside-line prefix is still required before 911.
2. No emergency notification is configured at all.
3. One address covers an entire multi-building campus.
4. Floors and sublocations were never defined.
5. Remote users sit on the office default address.
6. Phones were physically moved without updating location configuration.
7. A new site opened with no emergency calling review.
8. Everyone assumed the carrier or cloud provider handled it.
9. Nobody tested after deployment.
10. Nobody has reviewed it since.

Items 6 through 10 are the same failure wearing different clothes: emergency location data goes stale silently. The phone system keeps working perfectly while the location it reports slowly stops being true.

What to do this week

A short, honest audit beats a long plan.

1. Establish your dates. When was the system installed, replaced or migrated? This determines which requirements attach.
2. Dial 911 the way a panicking employee would. From a desk phone, from the desktop app, from a common area phone. Do not place a live call — use your provider's supported test procedure. You are checking whether a prefix is required.
3. Find out who gets notified, and whether that destination is one a human actually watches.
4. Inventory emergency addresses per site. Not per company. Per site.
5. Decide whether you need sublocations. Multiple floors, suites, buildings or a campus almost certainly means yes.
6. Pick a name. Assign one person who owns emergency calling accuracy, and a review date. Without this, steps 1 through 5 decay within a year.

Emergency calling is an operational programme with an owner and a review cadence, not a deployment checkbox.

Frequently asked questions

Related articles

This is the pillar of the ADAM Pulse emergency calling series.

• How long does Zoom Phone number porting take? — emergency calling belongs in the migration plan, not after it.

References

Primary sources first. The CFR is the rule; the FCC's web pages are summaries of it.

1. 47 CFR § 9.3 — definitions, including "Dispatchable location" and "MLTS notification"
2. 47 CFR § 9.16 — MLTS direct dialing, notification and dispatchable location obligations
3. 47 CFR part 9, subpart F — applicability (§ 9.15) and compliance date (§ 9.17)
4. 85 FR 78018 (3 December 2020) — FCC notice announcing the January 2021 and January 2022 compliance dates
5. FCC Report and Order 19-76 — Implementing Kari's Law and Section 506 of RAY BAUM's Act — PS Docket Nos. 18-261 and 17-239, GN Docket No. 11-117; adopted 1 August 2019, published at 84 FR 66716. Adopts the rules; does not contain the January 2021 and 2022 compliance dates.
6. FCC — Multi-line Telephone Systems: Kari's Law and RAY BAUM's Act 911 requirements — plain-language summary. Useful for orientation; cite the CFR for the rules.
7. National 911 Program — Kari's Law and RAY BAUM's Act summary (PDF, October 2020)