Best practice for Business Portal password reset

[sn-ushi]

Hi Community,

We are using the ServiceNow Business Portal (CSM) for external customers and have a question about the recommended password-reset process.

Current configuration:

• Password Reset Process: Default Self Service

• Credential Store: Local ServiceNow Instance

• Identification: Email Identification

• Verification: Email Code Verification

• Minimum Verifications: 1

• Email/SMS Password Reset URL: Enabled

• Redirect URL: Business Portal

Current issue:

Our customers receive an email with a verification code. After entering the code, they receive a second email containing a password-reset link.

Previously, this process worked. However, some customers are now redirected to the Microsoft Entra ID login page instead of the expected password-reset page.

We checked the configuration and found no changes since August.

What we tested:

In our DEV instance, we disabled the Email/SMS Password Reset URL checkbox.

The process now works as follows:

1. Customer requests a password reset.

2. Customer receives a verification code by email.

3. Customer enters the code.

4. Customer is taken directly to the page to set a new password.

5. Customer successfully resets the password and logs in to the Business Portal.

The test was successful. However, the Security Score decreased from 72 to 62 after disabling the checkbox.

Our questions:

1. Is disabling "Email/SMS Password Reset URL" a recommended approach for external customers using the Business Portal?

2. Is Email Code Verification alone sufficient, or should we configure an additional verification method?

3. Are other companies using the direct password-reset process without sending a second email?

4. Are there any security risks or known issues with this configuration?

5. Would you recommend keeping the checkbox enabled and investigating the incorrect redirect instead?

We would appreciate hearing how others have implemented password resets for external customers and what ServiceNow best practices you recommend.

Thanks in advance!

[brianlan25]

Have you tried opening a case with support to see why they are getting redirected to the wrong location. Also I'm not sure why unchecking that would decrease the score by 10 points (I have never seen one setting change the score by that much). If I were a customer I would get annoyed with multiple emails and steps to reset my password. Most places I can do that I put in my code that I get via email or SMS and it takes me to a page to reset my password like your knew config.

On a side not it looks like you need to look at the security of your instance overall. I believe the ServiceNow recommendation is to be at least at 85%.

[Kailash Bhange]

Hi @sn-ushi,

I would keep "Email/SMS Password Reset URL" enabled and fix the redirect, rather than switch it off.

Why:
1. The docs describe the Email/SMS Password Reset URL as the secured reset method, enabled by default for self-service processes. When it is cleared, the process is expected to use stronger verifications. With only one verification (an email code), the emailed link is effectively doing the job of a second check, which is why your Security Score drops.
2. If you do go direct-reset, raise Minimum Verifications to 2 and add a second, independent verification (for example SMS code, or another method your customers can actually complete) so a mailbox compromise alone isn't enough.

What to check for the Entra ID redirect:
1. Copy the link from one of the failing emails and open it in a private browser window. Note the exact URL it lands on before the redirect. It should be the public password reset page; if it is first bounced to login, the page or its portal is being treated as requiring authentication.
2. Review Multi-Provider SSO: is an Entra ID IdP set as Default, or is auto-redirect to the IdP enabled? External contacts on the Local credential store should not be sent to Entra. Check the IdP's settings and any login/redirect properties changed by a recent upgrade or plugin update, even if the reset process itself wasn't touched.
3. Compare an affected and an unaffected contact: any difference in SSO source, domain, or whether they open the email in a corporate mail client that scans links. Some mail security tools pre-open links, which can consume a one-time reset link before the customer clicks it.
4. Check the email's link base URL matches the Business Portal URL and your instance's public URL, and the Redirect URL is a full https path (or starts with "/" if on the same domain).
5. Check syslog / transaction logs around a failing attempt for the pwd_reset page request and what redirected it.

If you find the redirect is caused by an SSO setting, you can usually exclude the reset pages or the portal from IdP auto-redirect and keep the more secure two-step flow.

If this helps, please mark it helpful, and accept it as the solution if it resolves your issue

[mugi-san]

Hello, @sn-ushi .

Could you think of any potential implementation factors that might cause the redirect to Entra ID?

If this issue is tied to specific customer environments, taking measures that elevate security risks simply to fit those environments might not be advisable.

Given the potential security risks for other customers using the CMS, we may want to check if it is truly permissible to uncheck that box.

regards,

[sanjaygupta]

Hi, 

I would recommend keeping Email/SMS Password Reset URL enabled and investigating the Microsoft Entra ID redirect separately before changing the password-reset configuration.

1. Should Email/SMS Password Reset URL be disabled?

I would not recommend disabling this option solely to work around the redirect. ServiceNow documents it as a secure password-reset mechanism and enables it by default for self-service Password Reset processes.

Disabling it changes the reset flow and requires the remaining verification configuration to meet the applicable security requirements. ServiceNow warns that a weak verification configuration can allow an unauthenticated user to reset another user's password.

2. Is Email Code Verification alone sufficient?

This depends on the configured password-reset process and its security requirements. Email Code Verification helps verify access to the user's email account, but it should not automatically be treated as an independent second authentication factor.

If Email/SMS Password Reset URL is disabled, review the process configuration and ensure that the required multi-factor authentication (MFA) and verification requirements are satisfied. Do not disable the option in production until this has been verified.

3. Do other companies use direct password reset?

The successful DEV test demonstrates that the direct-reset flow works in your tested configuration. However, this alone does not establish that it is the recommended configuration for every external-customer portal. The appropriate approach depends on the configured verification methods and the security requirements of the implementation.

4. Are there any security risks?

Yes, if the remaining verification configuration is insufficient. ServiceNow warns about weak verification configurations when Email/SMS Password Reset URL is disabled.

The Security Score decreasing from 72 to 62 indicates a change in the calculated score, but the score alone does not establish whether the configuration is vulnerable. Review the documented scoring rules and security requirements before deciding whether the lower score is acceptable.

5. Should the checkbox remain enabled while the redirect is investigated?

Yes. Since the existing configuration reportedly worked previously and only some customers are affected, I would investigate the redirect before changing the password-reset security model.

I recommend checking the following:

1. Inspect the reset email and confirm the exact URL customers receive.
2. Verify the Redirect URL configured in the Password Reset Process.
3. Review the Multi-Provider SSO configuration, including the default identity provider and automatic redirection settings.
4. Compare affected and unaffected customers for differences in email domain, user records, or identity-provider mapping.
5. Test the reset flow in a private browser session to determine whether an existing Entra ID session affects the behavior.
6. Review relevant logs and trace the redirect to establish whether it originates from the password-reset flow, portal configuration, or SSO authentication.

These checks will help determine whether the issue is related to the reset link, portal redirection, or identity-provider configuration. The available information does not yet establish Entra ID SSO as the confirmed root cause.

Recommendation

I would keep Email/SMS Password Reset URL enabled while investigating the incorrect redirect in a sub-production instance. If the redirect can be corrected without weakening the password-reset verification requirements, that would preserve the existing security configuration.

If the issue persists, raise a ServiceNow Support case with the release version, relevant password-reset settings, affected reset URL, and troubleshooting results.

Reference documentation:

• Password Reset Process form — ServiceNow

I would treat the successful DEV test as useful troubleshooting evidence, but not as proof that disabling Email/SMS Password Reset URL is the recommended production configuration.