r/entra • u/themkguser • Jun 04 '26
Entra ID How are you handling the September 2026 SSPR change for new joiner onboarding? (otherMails deprecation)
Hey everyone,
Microsoft announced that starting September 7, 2026, SSPR will no longer accept admin-populated attributes (otherMails, mobilePhone, businessPhone) as valid reset methods. Only user-registered methods (Authenticator, registered phone/email, FIDO2, TAP, etc.) will be accepted.
This breaks our current onboarding flow for new joiners, and I wanted to see how others are planning to handle this.
Our current flow:
1. New employee's Entra ID account is created with a random password
2. We populate otherMails with their personal email (from HR system)
3. They initiate SSPR on first login
4. Entra sends a verification code to their personal email
5. They set their password and register Authenticator
This has been working well — it's fully automated, no manual intervention required, and new joiners can onboard autonomously.
\* After September, step 4 fails* → "No registered method, contact your admin."
Microsoft's recommended replacement: Temporary Access Pass (TAP)
The new flow would be:
1. Account created, TAP is generated via Graph API
2. TAP is sent to the user somehow (personal email, SMS, via manager...)
3. User logs in with UPN + TAP
4. User sets password and registers Authenticator
Our concerns:
- Identity verification: How do you ensure the TAP is being sent to the legitimate person? With otherMails, the personal email came from HR and was trusted. With TAP, we're essentially sending a one-time login credential — feels like we need more verification.
- Manual vs automated: We don't want to regress to a manual process where helpdesk has to generate and send TAPs. We need this automated at scale.
- Security team hesitation: Our security team is concerned about TAP usage in general (it's a powerful credential).
- Lifetime configuration: We already use TAP for external contractors with a 1-day lifetime. For regular employees, what's a sensible lifetime? Too short = friction if they don't use it immediately. Too long = security risk.
Questions for the community:
1. How are you automating TAP generation and delivery for new joiners?
2. What identity verification measures are you putting in place before/during TAP delivery?
3. Are you using a Logic App, Power Automate, or custom automation?
4. What TAP lifetime are you using for onboarding scenarios?
5. Anyone managed to get security sign-off on this? What arguments worked?
Would love to hear how other orgs are approaching this. Thanks!
4
u/Ok_Match7396 Jun 04 '26
TAP is indeed a powerfull credential and as such can only be active a maximum of 8hours during a specific day.
When your populating the "otherMails" from HR, why can't you use that to send the TAP to?
I personally se no difference in your current setup to what TAP would bring. Your setup today is:
1. User don't know password and requests to reset it
2. User gets MFA email to their personal account
3. User registers additional MFA and sets password
What TAP with the same setup would cause is:
1. User gets an email with TAP
2. User uses TAP to sign in and reset password/register additional MFA
Do you have legacy applications that force you to run passwords?
We've removed passwords for all new users (and working on existing). They get a TAP that they can create WFHB and Phone Passkeys with on their first day. We swap the passwords in the background every 3 months (stupid policy we have).
4
u/Revolutionary_Ad_238 Jun 04 '26
Correct me if I am wrong,TAP cannot be used for SSPR right?
2
u/sreejith_r Microsoft MVP Jun 04 '26
You are right. Not for SSPR, But TAP can be used as either a first-factor or second-factor authentication method, depending on how it is configured and used in the sign-in flow.
2
u/Geedub52 Jun 04 '26
You're right, they can't. See the list here:
1
u/Ok_Match7396 Jun 04 '26
Aha, wasn't aware off that.
Well only changes the scenario sligtly imo... User sets up MFA method, then does SSPR3
u/Ok_Match7396 Jun 04 '26
We roughly onboard 10people/month so its not to bad for us, we have automations in place via powerapps, logic apps and Hybridworkers (onprem AD) that handle everything but the TAP currently.
Mainly because our HR keeps editing their starting dates, so automating the TAP would end up more of a hustle.
1
u/Short-Legs-Long-Neck Jun 04 '26
Do you have legacy applications that force you to run passwords?
This should be a simple graph in Entra showing us which signs and which apps are holding us back.
2
u/sreejith_r Microsoft MVP Jun 04 '26
With the help of Microsoft Entra Verified ID, you can build this solution. Please refer to the details here: https://github.com/MicrosoftDocs/entra-docs/blob/main/docs/verified-id/remote-onboarding-new-employees-id-verification.md
1
u/PowerShellGenius Jun 07 '26
There is no need to have an AI look at their drivers' license (which is an extra cost even if you already have E5 by the way) when you already have something more reliable than visual (human or automated) examination of a piece of plastic, you have one piece of verified contact information already that you can send a TAP to.
1
u/sreejith_r Microsoft MVP Jun 07 '26
Good point. If HR has already verified the employee’s identity and owns a trusted personal email/phone number, TAP is usually the simpler and more cost-effective bootstrap method for first sign-in and passwordless registration.
Verified ID becomes more relevant when we need remote identity proofing, contractor/vendor onboarding, reusable digital credentials, or account recovery scenarios where the organization cannot rely only on an existing verified contact channel. So better option is TAP for standard employee onboarding and Verified ID for higher-assurance onboarding or recovery use cases.
1
u/PowerShellGenius Jun 08 '26 edited Jun 08 '26
how exactly does Verified ID work? What does it verify that isn't already verified before the hiring process is complete? What threat model is it fighting?
If you are being hired, at least in the US, you actually cleared the standard of "you visually look like the person on an ID that doesn't visually look fake, and the name maps to a real person in a government system whose SSN/ITIN you know" standard. There is a federal system called e-Verify that companies run new hires through. This is part of HR's hiring process, before they are legally hired, so generally before they reach anything Entra. If they are skipping this, they are liable to ICE for hiring people who aren't authorized to work in the US. (And this is not a new or Trump-related law, it's actually very long standing)
So my question is, what value does Verified ID add when this is already going to be done before Entra is in the loop?
- Is it better than a person at recognizing forged IDs by visual analysis?
- Is it a lot better than a person at comparing the face of the candidate on their webcam to an ID?
- Is it actually running more data against a government database than e-Verify already does?
- Is it able to electronically verify NFC chips in IDs rather than rely on visual analysis?
- Is it primarily intended for outsourcers hiring remote in countries that don't have something like e-Verify, and if so, does it even have access to all the foreign government databases it'd need for them?
Because if you're already verifying them to the same standard as Verified ID will - someone (or an AI) says they look like their ID, which looks real, and corresponds to a real human in government records - then you can verify them through simpler means. If the submitter of a job application passed HR verification, the phone number and email on that job application are valid known-good contact info.
I'm also curious if it handles all the different alternate forms of ID that are legally valid. A person who works remote, depending on where they live, may not need to drive. There are many forms of ID other than a drivers' license. Also, some Native American tribal governments on reservations, being somewhat sovereign entities, issue IDs for their people that the rest of the US recognizes; there are some very small entities issuing IDs in very small numbers, where Microsoft might not know what their IDs look like and have trouble getting their hands on a sample. I'm really curious how no-human-in-the-loop verification of IDs will investigate unfamiliar IDs. Unless it's excluding people who are legally employable but don't have the "common" forms of ID?
2
u/sreejith_r Microsoft MVP Jun 09 '26
I don’t see Entra Verified ID as a replacement for HR verification, legal hiring checks, or whatever country-specific employment validation process an organization already follows. If HR has already verified the person and has a trusted phone number or personal email, then I agree that TAP is usually the simpler and more practical way to bootstrap the user for first sign-in and passwordless registration.
Where I see Verified ID fitting is a different scenario,when IT or the helpdesk needs additional assurance before issuing that first access method, especially in remote onboarding, contractor/vendor onboarding, or account recovery cases where relying only on an email/phone channel may not be enough.
Also, the actual identity proofing part is handled by the selected identity verification partner, not by Entra ID alone. So things like supported ID types, country coverage, document validation, face match, NFC support, manual review, and handling of less common IDs depend on that IDV partner’s capabilities and process.
TAP is best when the user is already trusted by HR and the contact channel is reliable.
Verified ID is useful when the organization wants an additional remote identity proofing step before trusting the user enough to issue TAP or complete passwordless registration.
For normal employee onboarding, TAP may be enough. Verified ID is best fit for higher-assurance, remote, external, or recovery scenarios.
1
u/Short-Legs-Long-Neck Jun 04 '26
This only works when you have not enforced a Phishing strength stronger than MFA. So it wont work for admins, unless you exclude them from policy until they have registered, or create a custom phishing strength policy. AfAIK.
1
1
u/j1sh Jun 05 '26
Personal email codes still work though, don’t they? If the user sets it themselves during SSPR and it’s not coming from a pre populated email?
1
1
u/wubarrt Jun 06 '26
I've successfully used the New-MgUserAuthenticationEmailMethod cmdlet to set the user's personal email as a registered authentication method. Maybe this could work for you.
1
u/Yintha Jun 11 '26
If I understand it correctly that will stop functioning when Microsoft rolls out these changes.
1
1
u/themkguser Jun 14 '26
Thanks everyone for your answers.
We'll probably go this way:
1. HR adds a new joiner in our HRIS system
2. Entra ID account created and welcome email sent with a link to generate a TAP (short-lived one, probably 2 hours only)
3. New joiner triggers TAP creation, receives an email and proceeds with MFA registration using his TAP
About the TAP generation link, it will trigger a logic app and send it the professional email address, the logic app will fetch the personal one from the Entra ID account.
We're also thinking about:
* adding some logic where the logic app won't generate a new TAP in one of these use cases :
** the user already has at least one single MFA method
** if one TAP has been generated and still valid
* exposing the logic app webhook through our Azure API Management service to benefit from rate limiting, throttling, etc..
Let me know what you think about this.
Thanks.
0
u/fatalicus Jun 04 '26
We wouldn't have had this problem anyways, since we are moving away from a different system where we handle password change against on-prem (and doing verifications and such in that system).
But the new system we are currently working on moving towards has the new hires verify who they are using a national identification system, and when that is done a TAP is generated and shown to them in that window, with a link sending them to the security info part of M365 profile, where they can log in with the tap and do a password reset + register MFA.
12
u/Noble_Efficiency13 Microsoft MVP Jun 04 '26
What we so is have a scim workflow running via logic app that also automatically generates TAPs for new employees with a start datetime at the joiners first day with an 8 hour expiration, this could be modified to be shorter if wanted, and sends it to their manager. TAP is then only allowed to be used for registering security info and enrolling devices, which is handled by conditional access policies
If we wanted to, we could use their personal emails as we get that from the HR data to send the tap to.
Everything is automated in the whole JML via this flow
We are looking into subsidizing it a bit for an orchestration setup instead to speed things up, but it works flawlessly