When sign-in stops at verification, read the request on the screen before troubleshooting the phone. A request to enter a code is different from a request to approve a notification. FastPass is another sign-in capability whose availability depends on configuration.
For a Nordstrom-related account, the options displayed through your employer’s confirmed access route are the relevant starting point. This guide explains general Okta behavior without assuming that every method is enabled.
Match your action to the requested method
If the page asks for a code, locate the account that corresponds to the organization you are trying to access. Do not take a code from another account merely because it appears in the same application.
If the page expects a notification response, waiting for a code to change does not address the request. Read the sign-in screen and the notification together.
Okta’s Android instructions describe code, push and FastPass options and explain that the account must be set up in Verify before it can be used. These are documented product options, not a list of methods confirmed for Nordstrom. Okta Verify sign-in methods on Android
If no offered method is usable because a phone was replaced, go to the phone replacement guide.
Check the account before changing the device
A verification application can contain more than one account. Compare the organization or account information shown in the application with the account you intended to use.
This check is especially useful when a device has been used for different employers, test environments or separate work accounts. The question is whether the visible registration corresponds to the current request.
Do not delete unfamiliar entries as a first troubleshooting step. Identify them through the appropriate support channel if their purpose is unclear.
When an expected notification does not arrive
For iOS, Okta’s troubleshooting documentation includes checking the correct account, notification permissions, automatic date and time, and the current application version. Treat those checks as relevant to the documented platform rather than as a universal menu path for every phone. Okta Verify troubleshooting on iOS
Change one relevant setting at a time, then observe the result. Record whether a notification never arrived, arrived late, or appeared but could not complete the request. Those outcomes describe different symptoms.
Avoid creating a stream of simultaneous requests. A clearer test is one sign-in attempt whose time and result you can identify.
If the problem persists, report the phone platform, approximate attempt time and exact verification request to workplace support.
Treat an unexpected request differently
A request you did not initiate should not be approved simply to make it disappear. Okta’s Android guidance instructs users to reject an unrecognized request using the applicable denial or cancellation option. Okta Verify sign-in guidance
Report unexpected requests through the organization’s established security or IT channel. Do not post a screenshot containing a code or other sensitive account information in a public forum.
An unexpected request is not the same troubleshooting case as a missing notification during your own sign-in attempt. Keep those events separate in your report.
When verification succeeds but access still fails
Write down what happened after verification. Did a dashboard open? Did the browser return to sign-in? Did the intended application display its own error?
A successful verification action followed by an application failure needs a more precise description than “MFA does not work.” Use the application access guide if the failure occurs after entering the dashboard.
If results differ by browser or private mode, consult browser and session troubleshooting. That comparison can help identify the stage without assuming the phone is responsible.