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
- Can the user reach a self-service entry point and complete a recovery method on their own? → SSPR.
- If not — no enrollment, lost factor, first contact — → IVM, with verification decided inside the ticket.
- 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.