Recognize the Sign-In Prompt Before a Forgotten Device Becomes Risk

A finance team at a 3,200-person SaaS company approved a sign-in prompt from an old iPad sitting in a drawer. The user thought it was a routine MFA check. It was actually a replayed session recovery attempt from a device that had not checked in to MDM for 214 days.

That is the core problem: the device you forgot you logged in on still participates in your identity perimeter. If you cannot reliably recognize the sign-in prompt and tie it to device health, session age, and user intent, you are not doing adaptive access. You are outsourcing trust to memory.

Why the forgotten device is now an identity problem, not just an endpoint problem

A stale device used to be an asset management nuisance. In 2026, it is an authentication risk because modern sign-in flows span passkeys, push approvals, device-bound tokens, browser sessions, and conditional access policies.

Three trends make this worse:

• Users authenticate across 5-9 active devices on average in hybrid enterprises
• Session lifetimes are longer because reauthentication hurts conversion and productivity
• Attackers increasingly target approval fatigue, token replay, and unmanaged-but-previously-trusted devices

A realistic example: an engineering lead signs in to Microsoft 365, GitHub Enterprise, and an internal Backstage portal from a personal MacBook during an incident. Six months later, the laptop is sold, but the browser profile still contains recoverable session artifacts. The next sign-in prompt lands on the engineer's phone. They approve it because the location looks familiar and the app name is expected.

The failure is not MFA. The failure is context.

What a trustworthy sign-in prompt must answer

When a sign-in prompt appears, your stack should answer these questions in under 500 ms for the policy engine and under 2 seconds for the user-facing decision:

1. Is this device still enrolled and healthy?
2. Has it checked in recently?
3. Is the session bound to hardware, browser, or app instance?
4. Does the prompt match a user-initiated action in the last 60 seconds?
5. Is the device one the user actually recognizes?

If you cannot answer at least four of those five, the prompt should not be silently trusted.

Build a signal chain that can recognize the sign-in prompt with confidence

You need more than an IdP log line. You need a signal chain across identity, endpoint, and session telemetry.

Minimum signals to collect

At minimum, correlate these attributes:

• Device ID from MDM or EDR: managedDeviceId, serial, complianceState
• IdP authentication context: authMethods, tokenProtectionStatus, riskLevel
• Session metadata: browser family, app instance ID, cookie age, refresh token family
• User intent signal: app launch event, recent deep link click, SSO initiation timestamp
• Network context: ASN, geovelocity, private access path, ZTNA connector ID

For example, if Okta FastPass or Microsoft Entra ID reports a valid push channel but Intune or Jamf shows the device as non-compliant and last seen 97 days ago, the sign-in prompt should be downgraded from "approve with MFA" to "block and re-register on a managed device".

A reference decision model

Use a weighted policy rather than a single hard rule. This reduces false positives while still catching stale-device approvals.

policy: recognize-sign-in-prompt
version: 2026-04
inputs:
  device_last_checkin_hours: 214
  device_compliant: false
  token_bound_to_device: false
  user_initiated_login_within_seconds: 60
  push_number_matching: true
  impossible_travel: false
  session_age_days: 143
scoring:
  stale_device: 35
  non_compliant_device: 30
  unbound_token: 20
  no_recent_user_intent: 25
  long_session_age: 15
thresholds:
  allow: 0-24
  step_up: 25-49
  block_and_reenroll: 50+
outcome: block_and_reenroll

This model is simple enough to implement in most policy engines. In practice, teams often see a 40-60% reduction in risky push approvals after adding device recency and user-intent checks.

Architecture pattern that works

The cleanest pattern is event-driven correlation rather than synchronous API chaining on every login.

[User Action] --> [App/Portal Launch Event]
                    |
                    v
             [Event Bus / Kafka]
                    |
     +--------------+--------------+
     |                             |
     v                             v
[IdP Auth Events]             [MDM/EDR State]
     |                             |
     +--------------+--------------+
                    |
                    v
          [Risk Correlation Service]
                    |
                    v
         [Conditional Access Engine]
                    |
                    v
      [Approve | Step-up | Block | Re-enroll]

This avoids adding 300-800 ms of API latency at the point of sign-in. Most enterprises can keep median policy evaluation under 200 ms if they precompute device trust scores every 5-15 minutes.

Turn vague MFA prompts into prompts users can actually verify

Most sign-in prompts fail because they ask users to approve an event they cannot confidently identify. "Are you trying to sign in?" is weak. "Approve sign-in from Chrome on MacBook-Pro-14, last used 8 minutes ago, from Bucharest office network" is much stronger.

Prompt design changes that reduce bad approvals

Use prompts that include:

• Device display name the user recognizes
• Last active timestamp
• App or relying party name
• Approximate location and network type
• Number matching or challenge code
• Clear warning when the device is stale or unmanaged

A practical benchmark from large identity deployments in 2025-2026: number matching alone cuts accidental approvals sharply, but pairing it with device display name and recent activity context reduces help desk disputes by another 15-25%.

Here is a sample payload your approval service could render:

{
  "promptType": "sign_in_approval",
  "user": "alex.ivanov@company.com",
  "application": "GitHub Enterprise",
  "deviceName": "Alex-MBP-14",
  "deviceTrust": "stale_unmanaged",
  "lastSeen": "2026-09-18T08:14:00Z",
  "network": "Residential ISP, Cluj-Napoca",
  "challenge": "482931",
  "recommendedAction": "deny_and_report"
}

The key is not just richer data. It is understandable data. "Device trust: stale unmanaged" is more useful than a hidden risk score of 0.72.

Bind sessions to devices where possible

If your identity provider supports token protection or hardware-bound session credentials, enable them for high-value apps first:

• Admin portals
• Source code platforms
• Finance and ERP systems
• Customer data stores
• Privileged remote access tools

Device-bound sessions will not eliminate every stale-device problem, but they significantly reduce replay risk. Teams that roll out token binding to admin apps often cut token replay incidents by more than half, especially when combined with browser attestation and managed-device claims.

Implementation patterns across common enterprise stacks

The exact controls differ by vendor, but the pattern is consistent: correlate device state, enrich the prompt, and tighten session policy for stale endpoints.

Microsoft Entra ID + Intune + Defender for Endpoint

Use Conditional Access with device compliance, sign-in risk, and authentication context. Feed device recency from Intune and endpoint risk from Defender.

# Pseudo-automation for stale managed devices
$days = 90
$devices = Get-ManagedDevice | Where-Object { $_.LastSyncDateTime -lt (Get-Date).AddDays(-$days) }
foreach ($d in $devices) {
  Set-DeviceCategory -DeviceId $d.Id -Category "Stale"
  Revoke-UserSessions -UserId $d.UserId
  Add-ConditionalAccessTag -DeviceId $d.Id -Tag "block_push_approval"
}

A common policy split in 2026:

• Under 30 days since check-in: allow with standard phishing-resistant MFA
• 30-90 days: require step-up and device revalidation
• Over 90 days: block push approval; require managed re-enrollment

Okta + Jamf + CrowdStrike

Okta FastPass with device assurance works well when Jamf inventory is current. Add a Workflows job or event hook to flag devices that have not checked in and revoke refresh tokens tied to those users.

Named scenario: a creative agency with 1,100 Macs reduced suspicious approval events by 47% after changing their policy from "registered device" to "registered and seen in Jamf within 14 days".

Google Workspace + BeyondCorp Enterprise

For browser-centric fleets, context-aware access plus Chrome Enterprise signals can identify stale sessions faster than traditional VPN-centric controls. Pair browser profile management with short-lived sessions for admin roles.

A practical target:

• 8-hour session max for admin consoles
• 24-hour session max for source control admins
• 7-day max for standard productivity apps on compliant devices

Common Pitfalls

Even mature teams get this wrong because they optimize for convenience in the wrong layer.

Mistake 1: Trusting enrollment forever

A device that was compliant 6 months ago is not evidence of trust now. Set recency windows.

How to avoid it:

• Add last_checkin to every access decision
• Expire trust after 14, 30, or 90 days based on app sensitivity
• Revoke sessions automatically when MDM visibility disappears

Mistake 2: Treating every push prompt as equal

A sign-in prompt for Slack is not the same as one for a production Kubernetes dashboard.

How to avoid it:

• Tier applications by blast radius
• Require phishing-resistant MFA and device binding for Tier 0 and Tier 1 apps
• Show stronger prompt context for privileged apps

Mistake 3: Hiding device names users can recognize

Users approve what they can identify. Generic labels like "macOS device" or "mobile device" increase mistakes.

How to avoid it:

• Normalize device naming in MDM enrollment
• Display friendly names in prompts
• Include last activity and application name

Mistake 4: Ignoring shared and kiosk endpoints

Warehouse tablets, meeting room systems, and contractor laptops often sit outside normal recency rules.

How to avoid it:

• Tag shared devices explicitly
• Use app-specific sign-in restrictions
• Force shorter sessions and local sign-out on inactivity

Mistake 5: Measuring MFA success instead of approval quality

A 99% push approval rate can hide a terrible security posture if users approve prompts they do not understand.

How to avoid it:

Track:

• Approval-to-user-intent match rate
• Prompts denied then reported as suspicious
• Median device age at approval time
• Session revocations from stale devices
• Help desk tickets tied to confusing prompts

A strong target is over 95% prompt-to-intent alignment for privileged apps and under 2% approvals from devices not seen in endpoint management within policy windows.

Operationalize recognition with metrics, automation, and user education

You do not need a massive IAM transformation to improve this. Start with one workflow: detect stale devices, change prompt behavior, and revoke risky sessions.

A weekly control loop

Run this every week:

1. Export devices with no MDM or EDR check-in for 30, 60, and 90 days
2. Correlate them to active IdP sessions and recent MFA prompts
3. Revoke sessions for high-risk apps
4. Notify users with a self-service re-enrollment path
5. Review denied prompts to tune false positives

Here is a lightweight pseudocode example:

for device in devices:
    if device.last_checkin_days > 90:
        mark(device, "stale")
        for session in get_sessions(device.user):
            if session.app in HIGH_VALUE_APPS:
                revoke(session)
        send_notice(device.user, "Your old device can no longer approve sign-ins. Re-enroll a managed device.")
    elif device.last_checkin_days > 30:
        require_step_up(device.user)

Train users on one decision, not ten

Most awareness programs fail because they teach abstract security concepts. Train users to answer one question: Do I recognize this sign-in prompt and the device it refers to?

Good training copy is short:

If you did not start a sign-in in the last minute, deny the prompt. If the device name looks old, unfamiliar, or generic, deny and report it.

That single rule is more effective than a long MFA explainer.

Budget and performance reality

This control is usually cheaper than teams expect because the data already exists in your stack. The main work is correlation and policy tuning.

Typical 2026 effort for a mid-market enterprise:

• 2-4 weeks to wire IdP, MDM, and EDR events into a correlation service
• 1-2 weeks to redesign approval prompts or approval messaging
• 2-3 policy iterations to reduce false positives below 5%

If you build the correlation service in-house on Kafka plus a lightweight rules engine, expect low single-digit milliseconds for event ingestion and 100-250 ms for cached policy decisions. If you do live API fan-out on every login, expect tail latency to spike past 1 second during provider throttling.

Key Takeaways

• Treat the forgotten device as an identity risk, not just an endpoint inventory issue
• To recognize the sign-in prompt, correlate user intent, device recency, compliance state, and session binding
• Enrich prompts with device name, last activity, app name, and challenge code so users can make a real decision
• Block or step up approvals from devices not seen by MDM or EDR within your policy window
• Measure approval quality, not just MFA completion rate
• Start this week by revoking sessions from devices that have not checked in for 90 days and updating your prompt text for high-value apps

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