Use case
OTP delivery for enterprise and workforce access
Add multi-channel OTP to workforce sign-in, remote access and internal approval flows while keeping the identity platform and access policy you already use.
What the flow must protect
What the OTP shows
- The person requesting access currently controls a destination registered to that employee or contractor record.
- The otpId your access system stored on that access request was validated once.
- The attempt history can be reconciled with the access decision your identity platform recorded.
What it does not show
- That your access policy is satisfied. Flow2FA transports and verifies codes; it is not your IdP, VPN or access-control platform.
- That the device is trusted. Device posture and management remain your platform’s responsibility.
- That the request is phishing-free. OTP can be relayed, which is why privileged access deserves stronger factors.
Where the flow breaks
Single carrier or provider dependency
One degraded route can stop an entire region signing in, and workforce access outages escalate quickly.
Employees abroad without roaming
Travelling and remote staff often cannot receive SMS, but do have data. A single-channel policy locks them out.
Unmanaged fallback
Falling back to a personal mailbox for privileged access changes the assurance level without anyone approving it.
Shared destinations and helpdesk recovery
Shared mailboxes, team numbers and generous helpdesk overrides quietly undo the control the challenge was meant to add.
No joined-up audit trail
When the identity platform logs access and the messaging platform logs sends, nobody can reconstruct a single access event end to end.
Role and risk-based factor and fallback policy matrix
Not every role should be able to sign in, or fall back, the same way. This is a starting policy shape to adapt to your own role tiers.
| Role tier | Required factor | Permitted OTP channels | Fallback allowed | Escalation |
|---|---|---|---|---|
| Standard employee | Password + OTP | SMS, email, and WhatsApp where configured | Yes, to another enabled channel | Helpdesk reset after identity check |
| Privileged / admin | Phishing-resistant authenticator recommended where practical; OTP as interim step-up otherwise | Narrower set defined by policy, typically excluding SMS where alternatives exist | Restricted or disallowed | Security team review before any override |
| Contractor / third party | Password + OTP, time-bound to engagement | SMS or email only, scoped to approved destinations | No | Access revoked automatically at engagement end |
| Break-glass | Defined emergency-access procedure with mandatory post-use review | Channel set fixed in advance, not chosen at time of use | No | Mandatory logged review after every use |
Phishing-resistant authenticators (such as passkeys / FIDO2) are recommended for privileged access wherever your platform can support them; OTP over any channel remains a possession check that can be relayed.
A production flow
The access system decides a challenge is needed
Your IdP, VPN concentrator or internal application applies its policy and requests a second factor.
The request reaches Flow2FA
Submitted over REST or an SMPP v3.4 bind. REST returns an otpId, which your access system stores against the pending access request.
An approved route and channel are selected
Routing follows workforce policy, including any country or channel restrictions you set.
Fallback runs within policy
Only the channels you permit for that role or access class are used as fallback.
The code is verified
Verification enforces lifetime, single use and attempt limits.
The result returns to the access system
Your IdP or VPN receives the verification outcome and applies its own access decision.
Attempt and access outcome are recorded
Record the Flow2FA validation outcome against your own access record so security reviews can follow one event across systems.
How Flow2FA fits
Keeps your identity platform in place
Flow2FA is the delivery and verification layer behind whatever already decides who gets access.
Reach for staff who cannot receive SMS
Email, and WhatsApp over data where configured, give travelling and remote workers a path when the mobile network does not cooperate.
Controls to define, and what to measure
Controls to define
These are your decisions. Flow2FA carries and verifies the code; the policy stays yours.
- Role-based challenge policy, including which roles may use OTP at all
- Stronger or phishing-resistant factors for privileged and administrative accounts
- Destination lifecycle: joiner, mover and leaver updates and offboarding
- Helpdesk recovery rules and who may override a failed challenge
- Attempt limits, rate limits and lockout behaviour
- Country and channel restrictions for travel and contractor scenarios
- Prohibition of shared or team destinations for individual access
- Logging, retention and export for security review and internal audit
What to measure
Measure completed verification, not accepted API calls. Acceptance and delivery receipts are progress indicators, not outcomes.
- Access verification completion rate
- p95 latency from challenge to delivery attempt
- Helpdesk tickets related to access challenges
- Fallback rate for remote and travelling users
- Completion split by region and operator
- Failed attempts per access event, and cost per verified access event
Integration options
Enterprises frequently have both paths already: an internal messaging platform on SMPP and identity services that speak HTTP. Flow2FA accepts either, and many organisations use one for legacy systems and the other for newer ones.
Shared integration detail
REST vs SMPP, the provider model, routing and fallback, and full channel detail are covered once, in full, on the OTP API overview. For how to weigh those choices against your own requirements, see the buyer guide.
Channel availability depends on the setup configured for each account. The current public REST reference documents SMS and email channel values, while configured Flow2FA setups may also include WhatsApp.
Give remote staff a code path that works where they are
Tell us which regions and access systems cause the most lockouts. We will map REST and SMPP options against your existing identity platform.