Okta Verify push notifications not arriving on enrolled devices

TL;DR — If Okta Verify push prompts are not arriving on an already-enrolled device, the most common causes are device-level notification suppression, blocked outbound connectivity to Apple/Google push services, or stale/re-broken device enrollment after restore/reinstall. Start by sending a test push from the user’s factor/device page, then check the phone’s notification permissions and battery restrictions, then validate network egress to APNs/FCM before re-enrolling the device. Reading time: ~6 min

The scenario

It’s Tuesday at 3:40 PM. A developer on your team can sign in with password, but every MFA challenge just sits on “Push sent” until it times out, and they’re already locked out of the VPN and your staging admin panel. The user swears the phone is online, Okta Verify is installed, and SMS fallback works, but no push banner ever appears. You need to determine quickly whether this is a phone problem, a network egress problem, or an enrollment state that needs to be rebuilt.

Symptoms

• User sees a sign-in page or app prompt stuck on a waiting state after selecting push, typically wording like:

Push sent
Waiting for a response...

• After timeout, the user gets a failure such as:

Your verification request has expired. Try again.

• The enrolled device appears present in the admin/user factor list, but the phone shows no notification banner, no lock-screen prompt, and no badge increment.
• Manual opening of Okta Verify may or may not show a pending challenge; if it does not, the push likely never reached the device.
• SMS, voice, TOTP, or other non-push factors still work.
• Problem affects one device/user only, or many users on the same corporate Wi‑Fi/VPN after a firewall or MDM change.
• On iOS, the app may show notifications disabled or Background App Refresh off; on Android, battery optimization or notification channel suppression is common.
• On managed networks, outbound access to Apple Push Notification service (APNs) or Firebase Cloud Messaging (FCM) may be blocked, causing silent delivery failure.

Likely causes

Step-by-step diagnosis

1. Send a fresh push to isolate “delivery” from “user ignored it”. Use your identity provider admin console and open the affected user, then the enrolled Okta Verify device/factor entry, and send a push challenge or trigger a login that sends one.

   • This is your problem if: the console shows the challenge was sent, but the phone gets nothing after 30-60 seconds.
   • Jump to: device checks in steps 2-4, then network in step 5.

2. Check whether the app can show notifications at all. On the phone, open the app notification settings.

   • iPhone: Settings → Notifications → Okta Verify
   • Android: Settings → Apps → Okta Verify → Notifications
   • This is your problem if: notifications are off, lock-screen alerts are disabled, or a notification channel is muted.
   • Jump to: ### Notifications disabled or suppressed on the device

3. Check battery/background restrictions.

   • iPhone: Settings → General → Background App Refresh, then verify it is enabled globally and for Okta Verify; also check Settings → Focus if a Focus mode is suppressing alerts.
   • Android: Settings → Apps → Okta Verify → Battery and set to unrestricted/not optimized; also check Settings → Battery → Battery optimization.
   • This is your problem if: the app is optimized/restricted, background data is disabled, or Focus/Do Not Disturb suppresses notifications.
   • Jump to: ### Battery optimization / background restriction blocks delivery

4. Check for stale enrollment after reinstall/restore/device migration. Ask whether the user recently restored from backup, changed phones, cloned a work profile, or reinstalled Okta Verify.

   • This is your problem if: only this device fails, the app was recently reinstalled/restored, or opening Okta Verify shows no linked account/challenge despite the admin side still listing the device.
   • Jump to: ### Device enrollment is stale after app reinstall, phone restore, or OS migration

5. Test network egress to push backends from the affected network. This does not fully prove APNs/FCM reachability, but it quickly catches obvious proxy/TLS blocks.

curl -I --max-time 10 https://fcm.googleapis.com

Typical healthy shape:

HTTP/2 404
content-type: text/html; charset=UTF-8
server: ESF

Blocked/proxied examples:

curl: (28) Connection timed out after 10001 milliseconds

or

HTTP/1.1 403 Forbidden
Server: BlueCoat

Also test generic Apple endpoint reachability from the same network:

curl -I --max-time 10 https://api.push.apple.com

A TLS handshake or HTTP response is enough; a timeout or proxy block is the signal.

• This is your problem if: these calls time out, fail TLS, or return a corporate proxy block page only on the affected network/VPN.
• Jump to: ### Corporate Wi‑Fi, VPN, proxy, or firewall blocks APNs/FCM

1. Rule out bad device time. On the phone, enable automatic time/date/timezone, then retry a push.

   • This is your problem if: the device clock is visibly wrong or push starts working immediately after correcting time.
   • Jump to: ### System time on device is badly skewed

2. Check MDM/work profile policy if the device is managed. In your MDM dashboard, open the app configuration and restrictions for Okta Verify and the device’s assigned compliance/profile policies.

   • This is your problem if: notifications are disabled by policy, background data is blocked, work profile is paused, or the app is denied network access.
   • Jump to: ### MDM/work profile policy suppresses notifications or background data

3. Check for service-side incident only after local causes are ruled out. Use your provider status page and compare with a second user on a different network and device type.

   • This is your problem if: multiple users across unrelated networks/devices fail at the same time and status reports degraded push/MFA delivery.
   • Jump to: ### Provider-side outage affecting push delivery

Fixes

Notifications disabled or suppressed on the device

Turn notifications back on for Okta Verify.

• iPhone: Settings → Notifications → Okta Verify → Allow Notifications = On, then enable Lock Screen, Notification Center, and Banners.
• Android: Settings → Apps → Okta Verify → Notifications → Allow notifications = On; expand categories/channels and enable all Okta Verify channels.
• If Focus/Do Not Disturb is active, add Okta Verify to allowed apps or disable the Focus mode temporarily.

Verify it worked: send a fresh push and confirm a lock-screen/banner notification appears within 5-10 seconds.

Battery optimization / background restriction blocks delivery

Remove power-saving restrictions for the app.

• Android:
  • Settings → Apps → Okta Verify → Battery → Unrestricted or Don’t optimize
  • Settings → Apps → Okta Verify → Mobile data & Wi‑Fi → Background data = On
• iPhone:
  • Settings → General → Background App Refresh → On
  • Settings → General → Background App Refresh → Okta Verify = On
  • Disable Low Power Mode temporarily: Settings → Battery → Low Power Mode = Off

Trade-off: unrestricted battery/network use slightly increases background activity and battery consumption, but MFA apps are low-volume and this is usually negligible.

Verify it worked: lock the phone, send a push, and confirm it arrives without manually opening the app.

Device enrollment is stale after app reinstall, phone restore, or OS migration

Remove the broken enrollment and re-enroll the device.

1. In the admin console, open the user and remove the existing Okta Verify device/factor enrollment for the affected phone.
2. On the phone, uninstall Okta Verify if it is in a half-linked state.
3. Reinstall Okta Verify from the platform app store.
4. Start sign-in and choose the flow that re-enrolls Okta Verify, then scan the QR code or complete activation as prompted.

⚠️ Removing the factor can lock the user out if no alternate factor exists. Before deleting enrollment, confirm the user has another working factor (for example TOTP, SMS, or a temporary admin-issued recovery path).

Edge case: if the user restored a new phone from backup, push tokens from the old installation may not remain valid even though the app icon and data appear present. Re-enrollment is the fastest fix.

Verify it worked: the newly enrolled device receives a test push immediately and the old enrollment no longer appears in the user’s factor list.

Corporate Wi‑Fi, VPN, proxy, or firewall blocks APNs/FCM

Allow outbound connectivity to platform push services and stop TLS interception for those destinations where your network stack supports bypass rules.

• If you manage an egress firewall/proxy, allow HTTPS egress to the Apple and Google push endpoints used by mobile devices on your network. In practice, this means permitting APNs/FCM traffic and avoiding SSL inspection that breaks the client trust chain.
• Quick validation after policy change:

curl -I --max-time 10 https://fcm.googleapis.com
curl -I --max-time 10 https://api.push.apple.com

Expected shape is a normal HTTP/TLS response, not a timeout or proxy-branded block page.

If the issue only happens on VPN, split-tunnel mobile push traffic or disable the VPN briefly and retest. If it only happens on office Wi‑Fi, test the same phone on cellular; that A/B test is often enough to prove network causality.

Verify it worked: the same enrolled phone receives push on the previously failing Wi‑Fi/VPN without switching to cellular.

System time on device is badly skewed

Correct the phone clock.

• iPhone: Settings → General → Date & Time → Set Automatically = On
• Android: Settings → System → Date & time → Set time automatically = On and Set time zone automatically = On Then force-close and reopen Okta Verify, and retry.

Verify it worked: after time sync, a fresh push arrives and challenge approval succeeds without expiry errors.

MDM/work profile policy suppresses notifications or background data

Adjust the managed app/device policy in your MDM.

• Open your MDM dashboard and inspect the profile assigned to the affected device or group.
• Re-enable app notifications, background data, and background execution for Okta Verify.
• If Android work profile is paused, resume it on the device; paused work profiles commonly suppress app notifications.
• If your MDM has per-app VPN or network filtering, exempt Okta Verify from broken tunnels/filters and redeploy the policy.

Trade-off: loosening app restrictions may slightly reduce battery savings or increase background network allowance, but MFA delivery is time-sensitive and should not be aggressively constrained.

Verify it worked: after the policy syncs, the device receives a push while the work profile is active and the phone is locked.

Provider-side outage affecting push delivery

Use a fallback factor and stop burning time on local debugging.

• Confirm the incident on the provider status page.
• Temporarily direct affected users to a working factor such as TOTP, SMS, voice, or recovery code according to your org policy.
• If you have support entitlement, open a ticket with timestamps, affected users, device OS versions, and whether TOTP succeeds while push fails.

Verify it worked: users can authenticate with the fallback factor until push delivery is restored.

Prevention

• Add a helpdesk preflight checklist to your internal docs so first-line support collects the right data before escalation:

1. Device OS + version
2. Okta Verify app version
3. Managed or unmanaged device
4. Works on cellular but not Wi‑Fi/VPN? yes/no
5. Notifications enabled? yes/no
6. Battery optimization disabled? yes/no
7. Recent reinstall/restore/device migration? yes/no

• Keep at least one non-push factor enrolled for admins and developers. In your onboarding/offboarding checklist, require a backup factor before granting privileged app access.
• Add network monitoring for mobile push reachability from corporate egress points. A simple scheduled probe catches proxy/firewall regressions early:

#!/usr/bin/env bash
set -euo pipefail
for url in https://fcm.googleapis.com https://api.push.apple.com; do
  code=$(curl -I -sS -o /dev/null -w '%{http_code}' --max-time 10 "$url" || echo fail)
  echo "$(date -Is) $url $code"
done

Alert if results flip from normal HTTP/TLS responses to fail or consistent 403 from a proxy.

• In MDM, pin a policy baseline for MFA apps: notifications allowed, background refresh/data allowed, no aggressive battery optimization. Review this baseline whenever you roll out new battery-saving or per-app VPN policies.
• Add a post-device-migration check to your IT workflow: after phone replacement or restore, require the user to complete a fresh sign-in and confirm a test push before closing the ticket.
• Document a known-good A/B test in your runbook: retry on cellular with VPN off. It’s the fastest way to separate device/app issues from network egress problems during an incident.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.