Table of Contents
No Good Reason Why Users Can Update User Principal Names
Update 24 January 14:00 UTC: Microsoft appears to have reacted and has blocked the ability of users to update their UPNs. Here’s what the Entra admin center now displays when an attempt is made.

Update 26 January: An update released on Twitter by Alex Simons, Microsoft VP of Product Management, Microsoft Identity and Network Access Division, said:
“It was a bug caused by recent update to the service. When we the learned from Entra Advisors about the issue, team immediately rolled back to a known good build.
Fix in the newer build is completed and being rolled out slowly. We will do an internal investigation and PIR to identify the root cause and make process changes to prevent this (and any similar class of issues) from happening in future. Will also review log files for inappropriate usage and notify customers if found.”
It’s unclear if Microsoft has updated the default permissions assigned to Entra user accounts, but it is now possible for unprivileged users to update user principal names through interfaces like the Entra admin center and PowerShell. To be clear, an unprivileged user can update the user principal name for their Entra ID account and not for other accounts. Nevertheless, I can’t think of a good reason why any organization would want to allow people to update something fundamental like a user principal name, but they can.
To test the theory, I created a new account for Eric Hammon and attempted to sign into the Entra admin center. I then navigated to the Users section to access the account properties. As you can see from Figure 1, the user principal name is editable.

I went ahead and updated the account to make the user principal name Eric.B.Hammond@office365itpros.com. For good measure, I uploaded a new user photo. The update proceeded without a problem and the result is shown in Figure 2.

A side effect of updating a user principal name is that the user’s primary SMTP address also changes. This is because of the dual write arrangement between Exchange Online and Entra ID whereby updates to mail-related properties occur in both directories. The update to the user principal name also updates the account’s Mail property, and this ripples through to Exchange Online, meaning that the full set of proxy addresses includes a new primary SMTP address (indicated by SMTP:). The previous primary SMTP address is preserved as a proxy to make sure that Exchange Online can deliver messages addressed to the old primary SMTP address.
Get-Mailbox -identity eric.b.hammond@office365itpros.com | Select-Object -ExpandProperty emailaddresses SIP:eric.b.hammond@office365itpros.com SMTP:Eric.B.Hammond@office365itpros.com smtp:Eric.A.Hammond@office365itpros.com smtp:Eric.Hammond@office365itpros.com
If administrators reverse the the user principal name, the extra email proxy address will remain in place unless it is explicitly removed. The possibilities of impersonation are obvious. For instance, some could change their user principal name to CEO@office365itpros.com to get that email address and the change their user principal name back to revert to the original value. If administrators aren’t checking audit logs, they might miss this change.
Update User Principal Name with PowerShell
After validating that it is possible for a user to update their user principal name and photo via the Entra admin center, I tried with the Microsoft Graph PowerShell SDK (Figure 3). I expected this to work because much of the Entra admin center is built on top of the Microsoft Graph, especially anything to do with user accounts and groups (you can validate this by running the Graph X-Ray tool).

Essentially, these tests indicate that any tool based on the Microsoft Graph Users API will allow users to update their user principal name. I’m not bothered by the Entra admin center allowing people to update their photo because that facility is available elsewhere, notably in OWA and the new Outlook for Windows.
Blocking Access to the Entra Admin Center
Some control can be exerted for the Entra admin center by setting the option to restrict access to users that hold administrative roles (Figure 4).

This is only a partial block because accounts with relatively unprivileged roles, like Reports Reader, can still access the Entra admin center and update their user principal names. On the other hand, it does block casual access and is therefore a recommended setting to have in place.
Blocking Access to the Microsoft Graph PowerShell SDK
The ability to create an interactive session with the Microsoft Graph PowerShell SDK is governed by controls on the Microsoft Graph Command Line Tools enterprise app. Like other enterprise apps created by third parties for use in multiple Entra ID tenants, the instantiation for the app is a service principal that holds the consented permissions available in Graph SDK sessions. It can also hold a set of users and groups who are allowed to access the app. By default, the list of users assigned to the app is empty, which means that any user can run the Connect-MgGraph cmdlet in a PowerShell session to connect to the Graph.
Obviously, allowing open access to such a powerful capability isn’t a good idea, and tenants should take steps to secure access to the Microsoft Graph Command Line Tools app. With controls in place, anyone who isn’t on the approved list will see an AADSTS50105 error and be blocked from access (Figure 5).

And if you’re blocking access to PowerShell for the Graph SDK, consider doing the same for other Microsoft 365 PowerShellmodules.
No Apparent Justification for People to Update User Principal Names
Microsoft doesn’t make changes without reason, so something must have happened to convince the Entra ID developers to allow users to update user principal names. I can’t think of a convincing reason for such a change, but perhaps the logic will become apparent over time. In the meantime, if you don’t like people being able to change user principal names, consider applying the blocks described above.
Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.
Just wondering what happens when you have a synchronized environment and a user tries to change that information. Ideally it should get an error because the information won’t replicate back to Active Directory (I hope so)
I don’t have a hybrid environment so I can’t test. But it is easy to check.
For me it was updated properly and wrote back within next sync..
Thanks for testing. It makes sense that this should happen because Entra treats all the updates as equal and doesn’t know that this UPN update is generated by the user and not an admin. And of course, an admin could update their own UPN…
username change from cloud to on-prem is supported? how? wtf
I wish I know that.
Even I have an info “This user is synchronized with your local Active Directory. Some details can be edited only through your local Active Directory.” I can update the user name.
I can think of one reason why this is not a good idea: the integration of the user account name being used in the onedrive path on the client and other dependencies glued to the upn. For instance the onenote file. Maybe that all has been corrected but last time we had to change a upn it ment the user faced hreat difficulties accessing the Onenote (onedrive path is easily fixed)
I can confirm this is working multiple end-customer tenants.
I do not see Microsoft announcement for this change, or plan for it. Including justification.
It is also possible that someone changes to my-headquarters@company.com including username and email.
I do not see good reason for it.
Also, blocking the entra.microsoft.com is not a solution.
I have raised Microsoft Entra support ticket. I still believe this is unintenatinaly new feature/ bug / security concern.
Also no ability to fully control.
As part for user profile photos, similar thing, but can be adjusted using exchange – Set-OwaMailboxPolicy , but still does not resolve Microsoft Entra or other ways (graph?)
We have been considering blocking access to Entra ID admin center using CA, this might push us to that point. The fun part is blocking everything except for access by unprivileged app registration owners since they still need to modify client secrets / certificates.
Seen this too, and it was not it´s intention as I can understand – reported to MSRC and its´not possible anymore FYI.
Yep. The fix appeared in the last 30 minutes or so. Text has been updated.
I wish someone checked the logs and provided the details, how to detect it in Sentinel… I can only guess, that we could try something like
AuditLogs
| where OperationName contains “UPN”
The AuditLogs used by Sentinel are also available for interrogation by the Search-UnifiedAuditLog cmdlet, the Purview Audit solution, and the AuditLogsQuery Graph API https://practical365.com/audit-log-query-api/. These interfaces use the unified audit log (aka Microsoft 365 audit log) and the data flows from there into Sentinel. In all cases, look for the Update User event. The ModifiedProperties element of the AuditData payload tells you the old and new value of the properties altered for a user account.
Microsoft Support:
> I wanted to inform you that we have reproduced the issue on our side and reported it to PG (Many other customers reported the same). They have now fixed the bug.
> In the meantime, please consider this email as a reference while we check with our internal team regarding the KB article.
I guess they fixed it; I get a permission denied when trying to save my change
That’s what it says in the article.
Sorry I missed the update
[Action recommended] Please review your User Principal Name to ensure no unauthorized changes have occurred
You are receiving this message because of a recent configuration change introduced on December 20th, 2024, which caused unexpected behavior allowing member users without Admin roles to update their own User Principal Name (UPN). Member users without Admin roles can update only limited number of properties for themselves.
On Thursday, January 23rd, 2025, Microsoft Identity engineering determined the root cause to be a configuration change. We initiated the rollback of the configuration change on the same day and the issue was resolved by early morning (PT) of Jan 24th, 2025.
Microsoft security team conducted thorough investigations and concluded that there has not been any obvious sign of malicious activity in the logs. The related UserPrincipal Object IDs of the users who updated their UPNs without sufficient admin privileges can be viewed on the Impacted Resources tab. We recommend that you take action to verify the UPN values of these users are correct.
If you believe that you have received this message in error, or have any other questions or concerns, please open a support case at aka.ms/azsupt and refer to tracking ID ZTPH-7B8 in your case.
Yes it´s just got out – got notice about it 🙂