Resources · E911 and MLTS compliance
They are usually discussed together and satisfied separately. Most organizations that believe they are compliant have met the first and not the second.
Both statutes govern multi-line telephone systems, both are enforced through the same FCC rules, and both are typically raised in the same conversation. That makes it easy to treat them as one requirement with one fix.
They are not. One is about how a call is dialled and who is told. The other is about what the answering point learns about where the caller is. A system can do the first perfectly and fail the second completely, and that combination is common enough to be the default finding in a first assessment.
Three dates matter, and they bind different things. Getting them the wrong way round is the most common reason an organization believes it is out of scope when it is not.
February 16, 2020 — Kari's Law. Compliance with the FCC rules implementing Kari's Law is required from this date. The obligation attaches to multi-line telephone systems manufactured, imported, offered for first sale or lease, first sold or leased, or installed after it.
January 6, 2021 — dispatchable location, fixed devices. From this date an on-premises fixed telephone associated with a multi-line telephone system must provide automated dispatchable location to the answering point.
January 6, 2022 — dispatchable location, everything that moves. On-premises non-fixed devices and off-premises devices came into scope on this date. This is the deadline that catches soft clients, mobile handsets and remote workers, and it is the one most often missed, because the estate it covers is the part that changed most between 2020 and today.
Both dispatchable location obligations sit in 47 CFR §9.16, which is worth reading directly if you are deciding scope. The rule sets out a hierarchy rather than a single test: automated dispatchable location where technically feasible, and defined alternatives where it is not.
What each requires
| Kari's Law | RAY BAUM'S Act §506 | |
|---|---|---|
| Core requirement | Direct 911 dialling with no prefix or access code, plus notification to a central on-site location when a 911 call is placed | Dispatchable location delivered with every 911 call — a validated street address plus floor or suite detail |
| What it protects against | A caller who cannot reach 911 at all, or reaches it unnoticed on site | A caller who reaches 911 but cannot be found once responders arrive at the building |
| Nature of the obligation | Largely a configuration state — set correctly, it stays correct | A maintained state — it degrades as devices and departments move |
| Where it is codified | FCC MLTS rules applying to system managers, operators and installers | Phased in by device type under 47 CFR §9.16 |
| Typical failure | A legacy system that still requires a 9 to reach an outside line | A correct street address with no floor detail across a multi-storey building |
Direct dialling is a setting. Once a system is configured to route 911 without a prefix, it keeps doing that until someone deliberately changes it. Notification behaves the same way.
Dispatchable location is different in kind. It depends on a mapping between devices and physical places, and that mapping is invalidated by ordinary operational activity — a department relocating a floor, a batch of desk phones redeployed, a wing reconfigured. Nothing in the phone system flags that the location data is now wrong.
For mobile and soft-client devices the obligation is stated with an explicit feasibility test: automated dispatchable location where technically feasible, and an alternate location method where it is not. That distinction matters because a Teams or softphone estate is not exempt simply because the device moves.
The phrase is doing more work than it looks. A dispatchable location is a validated street address plus whatever additional detail is needed to find the caller inside the building — floor, suite, room, or an equivalent reference.
Two failure modes follow from that definition, and both pass a superficial check.
The first is an address that is validated but incomplete. A twelve-storey building returns a correct street address, responders arrive, and then search. The address was never the hard part.
The second is detail that exists but is stale. The location record says third floor, east wing; the team moved to the second floor in a refit eighteen months ago and nobody updated the record, because updating it was not part of the refit. This is the failure that a one-time deployment cannot prevent and only governance catches — which is the subject of a separate piece on why E911 compliance decays.
Five checks separate a Kari's Law problem from a RAY BAUM'S Act problem without needing an assessment first.
The second, fourth and fifth questions are the ones that tend to go unanswered, and all three point at governance rather than configuration. That is the practical difference between treating compliance as a project and treating it as a maintained state.
If you want to work through scope more formally, the FCC MLTS rule decision tree walks the same logic as a sequence of yes-or-no questions.
The obligation follows the organization managing, operating or installing the multi-line telephone system. In practice that means the exposure sits with the organization running the estate, not the integrator who configured it — which is why “our vendor handled that” is not a compliance position.
That responsibility cannot be transferred by contract. An integrator can be engaged to do the work and can be held to it commercially, but the regulatory obligation stays with the operator of the system. The distinction becomes concrete at the moment it matters, which is after an incident rather than before one.
It is also why this tends to be a corporate rather than a site-level question in any multi-property estate. One decision-maker holds it, even where the configuration decisions were made building by building.
At a single site, compliance is a technical question with a technical answer. Across a portfolio it becomes a programme question, because the properties are rarely at the same starting point and remediating them independently does not converge — each site drifts on its own schedule while the next one is being worked on.
That argument is set out in full in why property-by-property remediation fails across a portfolio, and in hotel-specific terms in Kari's Law compliance in a hotel, where the guest-room caller and the front desk introduce obligations a corporate office never encounters.
Cloud calling platforms are covered because the definition of a multi-line telephone system turns on function, not on where the equipment sits. An organization running Microsoft Teams as its phone system carries the same two obligations as one running an on-premises PBX.
What differs is where the gap appears. Direct dialling is rarely the problem on a modern platform — it is configured correctly by default in most deployments. Notification is more often missed, because it has to be pointed at a location and a person who will act on it, and that is an operational decision rather than a platform setting.
Dispatchable location is where hybrid estates struggle in particular. A single organization may run desk phones on a legacy system, Teams clients on laptops, and mobile handsets, each with a different mechanism for establishing where the caller is. Compliance is assessed against the call, not against the platform, so an estate is only as compliant as its weakest path to the answering point. An estate that passes on Teams and fails on the surviving PBX extensions has not met the obligation.
The migration itself is also a trigger. Moving from a legacy PBX to a cloud platform re-establishes every device-to-location mapping in the estate, which means a migration is either the moment compliance is fixed or the moment it quietly breaks.
Kari's Law and RAY BAUM'S Act §506 set a federal floor. Several states legislated on MLTS 911 access independently, some of them before the federal rules existed, and those statutes are not uniform — they differ on which systems are covered, what notification has to reach whom, and how location detail must be expressed.
Two consequences follow. A system that predates February 2020 and is genuinely outside the federal obligation may still be inside a state one. And a multi-state estate can be compliant in one jurisdiction and not in the next with identical configuration, which is a reason to establish position per property rather than per platform.
Confirm the requirements in each state you operate in rather than assuming the federal position settles it.
If you operate a multi-line telephone system — any system serving multiple telephones across one or more sites, including cloud platforms such as Microsoft Teams — it applies. The obligation attaches to systems manufactured, imported, offered for first sale or lease, first sold or leased, or installed after February 16, 2020.
There are two. On-premises fixed devices had to provide automated dispatchable location by January 6, 2021. On-premises non-fixed devices and off-premises devices came into scope on January 6, 2022.
Two things. Direct 911 dialling, with no prefix or access code required to reach emergency services. And notification to a central on-site location — a front desk, security post or equivalent — when a 911 call is placed from the system.
A validated street address plus the detail needed to find the caller inside the building, such as floor, suite or room. An address alone does not satisfy the requirement in any building where the address is not sufficient to locate a person.
Yes. Any organization using Teams as a multi-line telephone system carries both obligations, including Teams Phone with Direct Routing or Calling Plans, and hybrid estates that mix Teams with a legacy PBX.
Possibly, but the exemption is narrower than most assume. An upgrade to core hardware or software since that date generally brings the system into scope, and state law may impose obligations regardless of federal timing.
The organization operating the multi-line telephone system, not the vendor who installed it. That responsibility cannot be transferred by contract.
A multi-line telephone system: a system serving multiple telephones under shared control, whether an on-premises PBX, a hosted platform, or a cloud calling service. The term is defined by function rather than by technology, which is why cloud platforms are covered.
If you know which obligation you are failing, the E911 and MLTS compliance service covers assessment, deployment, PSAP testing and the annual governance that keeps a compliant estate compliant.
If you do not, that is what an assessment establishes. A multi-site assessment is offered at no cost and produces a position per property rather than a single verdict.
Related
Knowing the obligation is the first step. Establishing your position across every site is the second, and the multi-site assessment does that at no cost.
Full lifecycle — assessment, deployment, PSAP testing and annual governance across every site.
ResourcesThe FCC's decision logic, reproduced without interpretation, with what each outcome obliges you to do.
ResourcesWhy dispatchable location degrades through moves, adds and changes, and the cycle that prevents it.
The free multi-site assessment reviews your position across every site under both statutes. If you are compliant, you will be told so.