A password on its own is no longer a safe boundary. Credentials are phished, reused across services, sold on leak lists, and tried automatically against every open login screen. A second factor has become a baseline requirement of modern security architecture.
But adding MFA does not have to mean placing a separate verification service in front of every application, or moving the most critical moment of authentication entirely into a third-party cloud. Per-user recurring licensing costs, dependence on an outside service, separate management consoles, and a fragmented policy structure tend to complicate security over time rather than simplify it.
The bigger problem is the one-size-fits-all MFA approach. Not every application carries the same risk, not every user signs in from the same context, and not every session starts at the same trust level. TOTP may be enough for a corporate wiki; production servers and domain controllers should demand TOTP on every login with no trusted-device shortcut. A low-risk intranet app should not slow users down with code prompts at every login.
The job of MFA is not to constantly block the user but to raise the trust level when risk rises. To do that, verification decisions must be made based on the application, the user group, device state, location, session risk, and the sensitivity of the asset being accessed.
MFA should not be a separate cloud dependency; it should be a local, graded, and auditable part of your organization's own access policy.
Three factor types under a single policy engine, all running on the platform you already own.
TOTP, SMS, and email OTP are all driven by the same MFA configuration model. Administrators choose which methods are available globally, which are mandatory for a given service, and which are user-selectable — without touching separate vendor consoles or paying per-user MFA fees.
Each service or service group declares its own MFA requirement: no MFA, any factor, a specific method, or a chained combination of factors. Low-risk intranet apps stay frictionless; high-risk admin interfaces demand stronger requirements; nothing in between has to be over-protected to be safe.
When policy allows, users can mark a device as trusted at MFA time and skip the second factor for a configurable window — by default 30 days. Trust is bound to the device, not the network, and is revocable both from the admin console and from the user's own profile page.
Continuous trust evaluation watches every active session. If the operator's IP shifts country, the endpoint trust score drops, or behavior turns anomalous, the gateway can demand a fresh MFA challenge without forcing the user to start over from the login page.
Three factor delivery channels plus the policy and recovery tooling around them.
Standard time-based one-time passwords compatible with Google Authenticator, Microsoft Authenticator, Authy, 1Password, Bitwarden, Yubico Authenticator, FreeOTP, and every other RFC 6238 implementation. Enrollment runs through a QR code rendered server-side; the shared secret is encrypted at rest, never written to logs, and never exposed in the admin console. Algorithm, digit count, and validity window are configurable per profile.
OTP codes delivered by SMS through whichever HTTP-capable SMS provider you already use — Twilio, Vonage, Infobip, MessageBird, a local operator API, or your own internal gateway. The platform composes the message, calls the configured HTTP endpoint, and tracks delivery; no SMS reseller sits between your users and the codes they need.
OTP codes delivered to the user's verified email address. The login page only ever shows a masked form of the address (for example y***@example.com), so an attacker who has stolen the password still cannot learn the destination email. Useful as a recovery channel and for low-risk verification flows.
At enrollment time, TOTP users are issued a set of single-use backup codes — encrypted at rest, displayed once, and consumable when the user has lost access to their phone. Each consumed code is marked used and never accepted again; remaining codes can be regenerated by the user or by an administrator.
Administrators map MFA requirements per service, per service group, or per outcome. A given service can demand any factor, a specific factor, or a chain — for example TOTP at login plus a fresh SMS confirmation for cash-transfer operations. The matrix is versioned, auditable, and changes in one place propagate everywhere they apply.
When a single factor is not enough, services can require two or more factors in a defined sequence — for example TOTP at session start plus a fresh email or SMS code at the moment a sensitive operation is invoked. The chain is policy-driven and configurable; users encounter the extra step only where the risk warrants it.
A user who has already completed TOTP for a routine session can be challenged again mid-session when they reach a higher-sensitivity resource. The escalation is policy-driven, not a re-login, so the session continues and the user only handles the additional challenge — without losing context, open windows, or the work in progress.
Users enroll TOTP, regenerate backup codes, manage trusted devices, and verify their email or phone number from a single profile page — without filing a help-desk ticket. Administrators retain the ability to force a re-enrollment, revoke a trusted device, or reset a factor when identity verification requires it.
The plumbing that turns MFA from a checkbox into a defensible authentication layer.
TOTP secrets, backup codes, and trusted-device tokens are encrypted at rest using platform-managed keys, separated from session and policy data. Admin operators see metadata (enrolled, last used, trusted-device count) but never the secret value itself.
Each OTP channel keeps its own attempt counter — wrong TOTP entries, wrong SMS code entries, wrong email code entries — with configurable thresholds before the channel locks. The lockout is coordinated with the platform's broader login-attack-protection so a single user cannot brute-force one factor while a second factor is busy elsewhere.
Email addresses, phone numbers, and authenticator names are always shown to the end user in masked form on the verification UI. An attacker who has the password but does not own the second factor cannot read the destination to redirect — and a user looking over the shoulder of another cannot harvest enrollment details either.
Code length (6, 8, or higher), grouping separators (123-456 versus 123456), validity window in seconds, and resend cooldown are configurable per MFA profile. Compliance-scoped flows can demand longer codes with shorter windows; routine flows stay user-friendly with standard 6-digit, 60-second codes.
Users can request a code resend if the original did not arrive — subject to a configurable cooldown that prevents using the resend mechanism as an SMS-bombing primitive. Rate limits are tracked alongside the channel-specific attempt counters and surface in audit logs.
Every MFA attempt — successful, failed, resent, locked — is logged with timestamp, source IP, user agent, channel, and the decision the policy engine made. The audit stream feeds into the platform's SIEM streaming target so security teams can correlate MFA anomalies with the rest of their telemetry.
Domain controllers, production databases, the platform's own admin console — these demand the strongest available chain. A common pattern is TOTP at session start plus a fresh SMS confirmation at the moment a destructive operation is invoked, with no trusted-device shortcut for the highest-impact systems.
Cash-transfer and reconciliation systems can require a chained MFA — TOTP at login plus a fresh OTP at transaction time — so a single stolen factor cannot move money. Step-up policy keeps the friction at the transaction boundary, not at every page load.
Users without dedicated desks or trusted laptops authenticate with SMS OTP through the corporate SMS gateway, or with email OTP when SMS reliability is poor. Recipient masking and per-channel lockout keep the flow safe even when the same phone serves a shift.
Auditors look for MFA on every privileged access path to in-scope systems. Per-service policy makes the requirement explicit for the auditor without forcing the same wall in front of low-risk internal services.
Three methods, one policy engine, no third-party MFA cloud — configured per service and per risk. We'll walk through a live deployment on your applications.