Azure-docs: New SMS Short code numbers?

[miked1313]

Hello - We have received messages from Office 365 and Azure AD MFA from the following SMS short code numbers. If they are permanent can they be added to this FAQ? Thank you.

288402
75973
732873

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: d577f70e-9632-48ee-8e00-cead8e3cbd5b
• Version Independent ID: 44ebe4c6-0e6a-5ce4-554c-d4ed856e09c9
• Content: Azure Multi-Factor Authentication FAQ - Azure Active Directory
• Content Source: articles/active-directory/authentication/multi-factor-authentication-faq.md
• Service: active-directory
• Sub-service: authentication
• GitHub Login: @iainfoulds
• Microsoft Alias: iainfou

[JamesTran-MSFT]

Thanks for your feedback! We will investigate and update as appropriate.

[JamesTran-MSFT]

@miked1313
I was able to look into your issue and found the below snippet from the SMS short codes FAQ:

Link: SMS short codes
"There's no guarantee of consistent SMS or voice-based Multi-Factor Authentication prompt delivery by the same number. In the interest of our users, we may add or remove short codes at any time as we make route adjustments to improve SMS deliverability."

• Based off the above, is there a reason why you would like these short codes added to the FAQ?

Please let me know if you have any other questions.
Thank you!

[miked1313]

Hi @JamesTran-MSFT,
Our team has been seeing MFA SMS messages being sent from those short code numbers for a while now and we have lots of customers who use Office 365. I figured I would inquire as to whether or not they are new SMS short code numbers that the service uses and if so it would be helpful to add them to the FAQ since the FAQ has a list of a few known numbers. Better to be as complete as possible.

Thank you. :)

[JamesTran-MSFT]

@miked1313
Thank you for the feedback! I'll work with our internal teams and update as soon as possible.

[iainfoulds]

Thanks for the feedback, @miked1313

I've reached out to the engineering team to confirm if we need to update the list of in-use SMS short code numbers. If the amount of short codes in use has greatly expanded, it may not be viable to continue publishing.

Is there a specific reason for wanting to validate them - if the amount of short codes in was in the order of 10-20 possible numbers, would you expect users to confirm it was a valid short code sender? Is that what you're trying to do - make sure the sender is legitimate?

in-progress

[miked1313]

Hi @iainfoulds - Yes to either verify the sender, to tell users what numbers they may need to unblock, or sometimes our team has had to troubleshoot SMS delivery with wireless or telecom carriers. So we need a document like this that tells us what all the possible sender’s SMS short codes are. Hopefully Microsoft can continue to update this if engineering adds new SMS short code numbers. Thank you.

[shawnjburke]

@JamesTran-MSFT I'd like to support this request by voicing that I too think this has value. I am in this ticket because I want to know if 288402 is possibly fraud. My wife's phone received a reset request verification code, which she did not initiate. We all recognize this could be an honest mistake, but it could also be fraud. Having some idea that it belongs to Microsoft is useful.

"We can't keep it up to date".... ah the challenges of programming documentation. I think most of the community that needs this information understands that. Let's do the best we can. Perhaps we even consider building automation into a build pipeline that uses code documentation to auto-generate these sorts of documents. Microsoft has some great tools in Azure Dev Ops for this.

"We will stop using some"... also valuable to know at one time it was yours. I might suggest that for security reasons, Microsoft should pay close attention to what ones they own. If you stop using them, I'd suggest you keep owning them. Otherwise, some hacker will read this post, get smart, and go purchase the shortcode formerly owned by Microsoft and use it to commit fraud.

I think this ticket is an excellent opportunity for Microsoft to head off another security breach by keeping better track of this information. I can completely understand how difficult that must be, in a giant, global, organization like yours. That said, it's clearly in everyone's security best interest to be able to understand "Is this shortcode legitimate or fraud".

$0.02

[JamesTran-MSFT]

@shawnjburke
Thank you for your detailed response and great examples of why we should keep this list updated, with old and new SMS numbers.

@iainfoulds, the author of this doc, is currently reaching out to our engineering team for their guidance on this issue and will update as soon as possible.

Thank you both for your time and patience throughout this issue.

[miked1313]

Hi @JamesTran-MSFT - Did the engineering team provide any guidance on this request?

[JamesTran-MSFT]

@miked1313
Thank you for the follow up on this issue.

@iainfoulds
Since you're currently working with our engineering team on this, are there any updates from them?

[iainfoulds]

No, the engineering hasn't provided any updates to create a current list.

[MicrosoftGuyJFlo]

These numbers change often and we are unable to keep them up to date in real time as providers change the numbers frequently. #assign @MicrosoftGuyJFlo #please-close

[miked1313]

These numbers change often and we are unable to keep them up to date in real time as providers change the numbers frequently. #assign @MicrosoftGuyJFlo #please-close

It’s too bad that the service can’t update the phone numbers in the Azure Docs which are stored in GitHub. #DevOps?

[shawnjburke]

For History, let's point out that YOU CAN DO THIS. You are choosing not to. We are engineers. We put men on the moon before we even had a real digital infrastructure. We could keep a list of shortcodes updated if we wanted to. Now I'm not mad at anyone; I too understand the complexities of work to be done at a giant organization. Let's just note it's a choice. Your Microsoft; there are tons of people and a lot of them doing a poor job (tell you about my experience trying to get the hardware warranty on my ergonomic keyboard) and if we wanted to lead and direct them to get this done, it's achievable.

Which is why, when Microsoft comes up with some blow hard claim about how committed to security they are, some of us will remember moments like this. Also, when we ourselves get hacked (maybe it's Linked in again, maybe the check fraud I just went through), let's ask ourselves whether we contributed to better security or not when we had the chance.

Hard to do, is not the same as can't do.

Again, I understand the choice. No hatorade being spilled here. No shade being thrown. Let's agree however, that can't, just isn't really applicable here.