A Mobile Subscriber Integrated Services Digital Network (MSISDN) is the telephone number used to reach a mobile subscriber. In practice, it appears as the number used for calls or SMS delivery. Security teams treat it as personal data and use controls to prevent SIM swap fraud, account takeover, and unauthorised disclosure of subscriber contact information.
What an MSISDN looks like in practice
A practical MSISDN example is the phone number you would dial or text to reach a mobile line, often shown in international format with a country code and subscriber number. In real systems, that number is the address used by call routing, SMS delivery, billing, and customer-facing account records. It is not the SIM card itself or the IMSI behind the network subscription.
In everyday use, the MSISDN is the number a contact centre, app, or messaging platform stores when it needs to reach a subscriber. For example, a customer might register a mobile number for two-factor authentication, order alerts, or account recovery, and that same number then becomes the reference point for communications and subscriber lookup.
Because the MSISDN is externally usable and often tied to account workflows, it should be handled as personal data and as a sensitive identifier in operational systems. If it is exposed or changed without proper verification, the number can become a route into the account rather than just a contact field. That is why teams often pair it with stronger verification than SMS alone.
Where MSISDN sits in the mobile ecosystem
MSISDN is the subscriber-facing address, while other network identifiers support the carrier’s internal operation. That distinction matters because organisations sometimes confuse a public contact number with a network identity token. The practical result is that the same number can appear in CRM tools, fraud workflows, help-desk scripts, notification systems, and telecom back-end records, but each use case demands different handling.
In customer systems, the MSISDN may be used to match a person to a mobile account, to send one-time codes, or to recover a login. In carrier systems, it helps route calls and messages to the correct subscriber. A well-run process keeps that address stable unless a verified number change has been completed, because number reassignment or porting can affect both service delivery and security assumptions.
For teams that need a concrete operational example, the SIM Swap Fraud Guide is relevant because the MSISDN is often the first value attackers try to exploit when they take over a mobile line.
Why the example matters for security and privacy
An MSISDN is not dangerous on its own, but it becomes security-relevant when it is used as a login recovery factor, an identity lookup key, or a routing destination for sensitive messages. If an attacker can move the number through SIM swap or port-out fraud, they may intercept calls and texts, reset passwords, or redirect account notifications.
That is why privacy controls and identity controls intersect here. The number should be disclosed only on a need-to-know basis, and any process that treats possession of the phone number as proof of identity should be reviewed carefully. SMS can still be useful for notifications, but it is a weak standalone proof of control when fraud scenarios are in scope.
The practical risk shows up in support desks, telecom change requests, and any workflow that accepts the phone number as an implicit identifier. A good control set requires verification before a number is changed, ported, or reused, and it should log those events so security teams can investigate unusual activity.
Risk and Threat Considerations
An exposed or poorly protected MSISDN can support account takeover, SIM swap fraud, and privacy leakage. The risk is highest when business processes treat the number as both a contact method and a trust signal, because attackers can abuse that assumption to intercept messages or impersonate the subscriber.
Failure mechanism: If a number change, port-out, or SIM replacement is not strongly verified, an attacker can bind the victim’s MSISDN to a new SIM or service profile and receive calls or SMS intended for the real subscriber.
Impact: The result can be unauthorized account access, recovery-code interception, fraudulent customer support changes, and disclosure of subscriber contact information across connected services.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63 and NIST SP 800-53 Rev 5 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.5 — Principles relating to processing of personal data | MSISDN is personal data and must be handled with data-minimisation and confidentiality in mind. |
| Recommendation — Limit MSISDN collection and disclosure to what the workflow genuinely requires. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | SMS-reachable numbers are often used in identity proofing and recovery workflows that need stronger assurance. |
| Recommendation — Require stronger proofing before allowing a number to drive account recovery or changes. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MSISDN-based recovery and SMS delivery intersect with lifecycle controls for authenticators and recovery factors. |
| AC-2 — Account Management | Changing or reassigning the MSISDN affects subscriber account integrity and administrative change control. | |
| Recommendation — Manage phone-number-based recovery factors with lifecycle controls and revoke them when risk changes. Verify and log all number-change requests before updating subscriber account records. | ||
Practitioner Guidance
What to verify: Treat the MSISDN as an identifier that can be reused, ported, or reassigned. Before trusting it for account recovery or step-up workflows, verify that the number is still under the intended subscriber’s control and that any recent change was authorised.
Decision rule: If the MSISDN is used to receive authentication codes or recovery links, do not rely on it alone for high-value accounts. Move to stronger verification for number-change requests and review whether SMS should remain part of the recovery path.
What good looks like: Number changes are visible in logs, support staff have a strict verification script, and fraud monitoring flags rapid SIM or porting changes followed by password resets or MFA changes.
Practitioner takeaway: The MSISDN is best treated as a subscriber contact address with security consequences, not as proof of identity, so the control question is whether your processes can tolerate number interception or reassignment without opening the account.