Emergency services location: tiering account attributes by physical harm
Most account attributes are administrative. One of them decides where police and paramedics go. Treating both with the same authorisation strength is a design decision that nobody consciously made.
Which account attribute can get someone killed?
The registered emergency location. It determines where armed responders are dispatched, and it is changed through a self-service portal with the same authorisation as a billing address. Tiering attributes by physical consequence rather than by record type is the missing step.
- Registered location is a safety-critical attribute stored in a profile table alongside billing preferences.
- Consequence tiering classifies attributes by the harm a wrongful change produces, and assigns authorisation strength accordingly.
- This article deliberately omits operational detail that would assist misuse; the design question is what protection a field warrants, not how the field is abused.
Part of Telecom and subscriber identity
A framework, not an exposé
There is a category of harm in which a telecommunications record causes a physical response at a physical address. That is a narrow category and it deserves separate treatment from everything else in an account.
This article sets out a tiering method. It does not describe how registered location records are manipulated, because that detail would be useful to the wrong readers and adds nothing for the right ones.
What the obligations require
Federal requirements oblige providers to convey dispatchable location information with emergency calls. Kari's Law addresses direct dialling and notification in multi-line systems; RAY BAUM'S Act Section 506 addresses dispatchable location across service types, with compliance dates that have now passed for the major categories.
Those rules concern the accuracy and conveyance of location. They do not specify the authorisation strength required to change a registered location, which is left to the provider.
The tiering method
Classify every changeable account attribute by the worst realistic consequence of a wrongful change, not by its perceived sensitivity.
| Tier | Consequence of wrongful change | Example attributes | Authorisation strength |
|---|---|---|---|
| T1 | Physical harm to a person | Registered emergency location | Subscriber-held credential; no staff override without supervisor signature and delay |
| T2 | Financial loss or loss of account control | Payment method, SIM/eSIM profile, port authorisation, authorised users | Subscriber-held credential |
| T3 | Privacy or nuisance harm | Marketing preferences, call detail visibility | Session authentication |
| T4 | No external consequence | Display name, theme, language | Session authentication |
The exercise takes an afternoon and its main value is that it forces an explicit decision. Most organisations discover they have exactly one or two T1 attributes, which makes the control cheap.
Why registered location is T1 and address is not
A billing address change misdirects mail and enables some downstream fraud — serious, and squarely T2. A registered emergency location change determines where an emergency response arrives. Those are different categories of harm and they currently share a permission model.
It is also worth noting that the harm from a wrongful registered-location change falls on whoever lives at the address, who is frequently not the subscriber and has no relationship with the provider at all. That asymmetry is unusual and is part of what justifies the tier.
Designing the T1 control
Three properties, and the third is the one usually omitted:
- The change requires an assertion from a credential the subscriber holds, rendering the full address as it will be stored.
- The change notifies every enrolled authenticator and every contact address on the account, before it takes effect.
- There is a delay between authorisation and effect, long enough for a legitimate subscriber to notice a change they did not make and short enough not to impede a genuine move.
The delay is the property that protects against a compromise of the subscriber's own device, which no credential control can prevent by itself.
The accessibility constraint
A T1 control that a subscriber cannot satisfy is a T1 control that will be overridden by staff, which returns the attribute to T3 through the back door.
So the override must exist. Make it a signed supervisor exception with the same notification and delay properties, reported weekly. An override that is available, rare and attributable preserves the tier; an override that is available and unlogged destroys it.
What to do with the tiering output
Publish it internally as a standing classification, and require any new account attribute to be tiered at design time. The failure mode this prevents is the one that created the current situation: a safety-critical field added to a profile table because that is where fields go.
A consequence tier for subscriber attributes
| Tier | Examples | Gate |
|---|---|---|
| Cosmetic | Display name, preferences | Session |
| Financial | Billing address, payment method | Session plus notification |
| Access | Recovery contacts, SIM and port | Bound assertion |
| Physical | Registered emergency location | Bound assertion plus delay and confirmation |
Objections and honest limits
“Self-service location updates are a safety feature.” They are — an out-of-date location is also dangerous. The answer is not to remove self-service but to bind the change and confirm it, so both failure directions are covered.
“This is a rare attack.” Rare and severe, which is exactly the profile that justifies a gate. The cost of the control is one gesture on a change most people make when they move house.
Tiering subscriber attributes
- Classify by consequence, not by screen. What does changing this cause?
- Identify the physical-consequence set. Usually one or two attributes.
- Bind and confirm those changes. A signature, then an out-of-band confirmation of the new value.
- Notify on the old channel too. So a change made by someone else is visible to the real subscriber.
Terms used here
- Registered location
- The address associated with a line for emergency dispatch purposes.
- Consequence tiering
- Assigning authorisation strength by what a change causes rather than by which record it belongs to.
- Swatting
- Causing an armed emergency response to an address, which a falsified registered location enables at scale.
Frequently asked questions
Does this slow down a legitimate move? A delay measured in hours, with notification. Set it against how often subscribers change registered location, which is rare, and against the consequence of a wrongful change.
Who is protected by the T1 control? Primarily the occupants of the address, who are not the provider's customer and have no other protection.
Is this required by FCC rules? No. The rules address conveyance and accuracy of location information, not the authorisation strength for changing a registered location.
How many T1 attributes should we expect? Very few — typically one or two. If your tiering produces a long T1 list, the tier definition has drifted toward sensitivity rather than physical harm.
Why treat emergency location differently from a billing address? Because changing it dispatches armed responders to a physical place, and the consequence is not reversible in the moment.
Doesn't gating it make people less safe? An out-of-date location is also dangerous. Bind the change and confirm the new value, so both failure directions are covered.
How many attributes are in this tier? Usually one or two. That is what makes the control cheap.
Where this fits in Manav
Manav puts the subscriber or the authorising party back in the loop for the changes that matter, with a signature bound to the specific change and verifiable by a bank, a regulator or a counterparty without calling the carrier.
Sources and further reading
- FCC rules and regulations
- Public safety guidance on emergency response to reported addresses.
- FCC — protecting consumers from SIM swap and port-out fraud