When to Use FastPass SSPR vs FastPass IVM

Updated

Use FastPass SSPR when the user can still complete a self-service flow on their own — password reset, account unlock, or Temporary Access Pass issuance. Use FastPass IVM when self-service is not possible: the user never enrolled, lost the device holding their MFA factor, or is calling the help desk for the first time. Both are delivered by the same FastPassCorp platform, so you route each case to the right half rather than running two separate systems.

The dividing line: can the user finish it alone?

FastPassCorp frames its platform around a distinction between authentication and verification: authentication proves a device, verification proves a person. That distinction drives which product handles a given request.

  • If the user still holds a usable factor and can reach a self-service entry point, the request is a self-service problem → SSPR.
  • If the user cannot prove who they are through any self-service method, the request becomes a verification problem → IVM, handled inside the help desk ticket.

FastPass SSPR: self-service for users who can serve themselves

FastPass SSPR covers:

  • Password reset
  • Account unlock
  • Temporary Access Pass issuance

It works across:

  • Windows and Active Directory
  • Application-level systems accumulated over time (SAP, Oracle, IBM, and others)
  • Leading cloud identity providers

Access points include the PC client, a mobile browser, or any endpoint you choose — including before a user has successfully logged in. That last point matters: a locked-out user who cannot reach the normal desktop still has a path back in.

Choose SSPR when: the user can follow a self-service flow, has a usable recovery factor, and does not need a human to confirm their identity.

FastPass IVM: verified assistance for users who can't

FastPass IVM applies when self-service is not enough. The site names three typical triggers:

  • A user who never enrolled
  • A user who lost the device holding their MFA factor
  • A user calling in for the first time

In these cases, FastPass IVM runs the verification decision inside the ticket — the help desk agent works within the existing ticket flow rather than switching to a separate verification tool.

Choose IVM when: the user cannot complete self-service, and someone at the help desk must be sure the caller is who they claim to be.

Side-by-side

Dimension FastPass SSPR FastPass IVM
User situation Can self-serve Cannot self-serve
Typical triggers Routine reset, unlock, TAP issuance Never enrolled, lost MFA device, first-time caller
Who completes it The user Help desk agent, inside the ticket
Entry points PC client, mobile browser, any endpoint (including pre-login) Help desk ticket flow
Systems covered Windows/AD, SAP, Oracle, IBM, cloud IdPs Workforce identity verification at the help desk

Why the split doesn't disappear with passwordless

A common assumption is that passwordless methods remove the need for this kind of verification. FastPassCorp argues the opposite: a user who has lost the device holding their passkey still needs to get back to work, and someone still has to be sure it is really them. As identity providers tighten what counts as a valid self-service recovery method, more verification work moves to the help desk, not less. That is the case IVM is built for.

Practical routing rule

  1. Can the user reach a self-service entry point and complete a recovery method on their own? → SSPR.
  2. If not — no enrollment, lost factor, first contact — → IVM, with verification decided inside the ticket.
  3. Both run on one platform, deployed in the cloud or fully on-premises, on any identity provider you already run, so you don't need to stand up two systems to cover both paths.

FastPassCorp was founded in 2005, is headquartered in Copenhagen, and is listed on Nasdaq First North. The site offers an SSPR demo and an IVM demo if you want to see each path before deciding.