A customer who suddenly loses mobile service may be reporting more than a device problem. An unauthorized SIM change or number port can redirect calls and text messages, including security codes used by other services. Support teams therefore have to contain a live account risk, establish who is asking for help, preserve evidence, and restore service without giving an impostor a second path into the account. This study protocol shows how to evaluate that work from operational records.
The method is observational. It does not estimate the prevalence of SIM swap fraud, certify a carrier's compliance, or promise that a particular control prevents loss. It asks a narrower question: when a customer reported a suspected unauthorized change, did the support record show a coherent sequence of authentication, containment, investigation, restoration, and communication?
Define the incident before measuring recovery
Use the customer report, account events, and network events to define the unit. One incident begins with the earliest observable unauthorized-change signal and ends when the number is restored, the claim is rejected with a documented basis, or the case remains unresolved at the study cutoff. Merge repeat contacts about the same change. Keep a later, independent attempt as a separate incident.
Classify the initial signal: unexpected loss of service, notification of a SIM change, notification of a port request, unfamiliar device activation, failed authentication, or downstream account compromise. Do not label every service outage as fraud. Maintain separate states for suspected, corroborated, contradicted, and indeterminate incidents.
FCC 23-95 describes SIM swap and port-out fraud as distinct mechanisms and requires covered wireless providers to use secure authentication and provide notifications associated with SIM changes and port requests. The order is a regulatory source for control design, not proof that any sampled event was fraudulent (FCC 23-95).
Build a complete event chronology
Join support conversations with authentication decisions, SIM identifiers, device activations, port requests, notification events, account locks, credential resets, number-restoration events, and fraud-review actions. Preserve native timestamps and timezones. Record when each event became visible to the agent, since hindsight can make an earlier response appear less reasonable than it was.
The chronology should distinguish request time, approval time, execution time, and notification time. A notification generated before a change but delivered after service loss is not equivalent to a warning the customer could act on. Likewise, an agent note saying the account was secured is not evidence that a network change was reversed.
Retain contradictory records. If a port system reports cancellation while the number remains with another carrier, code the conflict and identify the source owners. Missing events should be marked unavailable, not silently treated as absent.
Test authentication as a sequence, not a pass/fail label
Record each authentication method offered, attempted, passed, failed, or bypassed. Include the channel and the information available at the moment of decision. A recovery flow that sends a code to the potentially compromised number needs to be distinguished from one that uses an independent possession factor or reviewed identity evidence.
NIST SP 800-63-4 provides current federal digital identity guidance across identity proofing, authentication, and federation (NIST SP 800-63-4). NIST SP 800-63A-4 also calls for redress mechanisms for proofing failures, delays, and compromised-account recovery (NIST SP 800-63A-4). These sources support evaluating secure recovery and redress together. They do not automatically bind a private carrier or prescribe one universal script.
Measure false starts and circular dependencies. Examples include requiring access to the disabled number, sending the customer from phone support to a store that cannot access the case, or repeatedly requesting documents already accepted. Review whether an alternate path existed for customers with disabilities, limited mobility, language needs, or no nearby retail location. Accessibility is part of completion, not a reason to waive necessary security.
Separate containment from restoration
Containment means preventing additional unauthorized changes while preserving legitimate recovery. Possible evidence includes a port freeze, account-change restriction, credential reset, fraud flag, suspension of high-risk self-service actions, or coordination with the receiving carrier. Code what the control actually did and when it took effect.
Restoration means returning the number or service to the verified customer and confirming that account access is stable. Measure time to first protective action, time to a definitive ownership decision, time to number restoration, and time to accurate customer confirmation separately. A fast temporary lock can be successful containment even when inter-carrier restoration takes longer.
Do not combine cases that were rejected for insufficient evidence with cases that were accepted but delayed operationally. The first concerns decision quality and redress; the second concerns execution and handoff. Both matter, but they imply different staffing and workflow responses.
Audit notification and customer instructions
The FCC's consumer guidance explains how port-out fraud can expose other accounts and encourages consumers to contact their carrier and financial institutions promptly (Port-Out Fraud Targets Your Private Accounts). Use that guidance to build a communication checklist, while avoiding claims that every incident caused downstream loss.
Review whether the customer received a clear account-change notice, an acknowledgment of the report, the current containment state, realistic next steps, and a case reference. Test whether agents distinguished "we blocked another change" from "your number is restored." Record whether advice about email, banking, or other accounts was framed as a precaution rather than a confirmed breach.
Compare message timing with system state. Premature certainty can be harmful: telling a customer that a port was reversed before the network record confirms it may delay protective action elsewhere. A conditional update that identifies what is known, unknown, and next can be more accurate than a fast closure message.
Examine handoffs and decision ownership
Map which team owns initial triage, identity review, network action, inter-carrier coordination, fraud investigation, and final communication. For every transfer, capture the reason, destination, acceptance event, and context passed. A transfer is not complete because one queue closed; the receiving owner must accept responsibility.
Review after-hours cases separately. If the fraud or port team is unavailable, determine which containment actions frontline staff can perform and what information they must collect for the next shift. Measure how often the account changed again while a case waited. That association can reveal exposure windows, but it does not prove that staffing alone caused the later event.
Sample for both risk and ordinary failure
Draw a stratified sample across suspected SIM swaps, suspected port-outs, false alarms, rejected recovery attempts, successful restorations, and unresolved cases. Include multiple contact channels and hours of operation. Oversample cases with repeated authentication, complaints, or downstream-loss statements, then weight descriptive totals if the report makes population estimates.
Two reviewers should independently code incident type, authentication adequacy, containment time, restoration state, notification accuracy, and handoff completeness. Publish agreement by field and adjudicate disagreements using the event record. If reviewers cannot consistently distinguish containment from restoration, revise the codebook before reporting rates.
Report findings with bounded conclusions
Useful outputs include the share of cases with a complete chronology, time distributions for containment and restoration, authentication restart counts, notification delivery evidence, unresolved ownership conflicts, and the proportion of closure messages supported by system state. Break results out by incident type and channel rather than presenting one blended average.
The study can identify where support evidence is incomplete or where a recovery path repeatedly stalls. It cannot determine criminal responsibility, prove that an unobserved action never occurred, or show that one control caused an outcome. Preserve queries, field definitions, policy versions, reviewer decisions, and aggregate analysis so a later study can use the same measurement frame.
For organizations designing secure escalation coverage, the practical conclusion is specific: staff need authority for bounded containment, a usable alternate authentication path, and an explicit owner for restoration. Customer Care Staff's phone and voice support and escalation and QA service pages describe the adjacent operating capabilities. The research method above is what turns those capabilities into testable evidence rather than unsupported assurance.