Multi-Factor Authentication

MFA at the gateway — for web, SSO, and SSH

Ixiea enforces multi-factor authentication where privileged access actually starts: the gateway login. Brokered SSH, RDP, and database sessions inherit that authenticated identity — no parallel MFA stack on every target.

MFA admin guideTalk to sales
Gateway choke point

Operators authenticate to Ixiea before any brokered session starts. SSH, RDP, and database paths inherit that login — targets never prompt for a second factor on their own.

Multiple factor types

OTP authenticator apps, passkeys, SMS, email, RADIUS OTP, and face recognition — enable the methods that fit your deployment and compliance posture.

Policy you control

Require MFA for all users, admins only, or per-user enrollment. Stack Ixiea MFA on top of SAML, OIDC, or LDAP primary auth when your IdP does not cover every path.

Authentication flow

One login, then brokered access

Operators authenticate to Ixiea first — via password, SSO, or SSH gateway auth. When policy requires it, MFA completes before a connection token is issued. Every subsequent brokered session rides on that authenticated identity.

SSOif requiredOperatorWeb or SSH clientIxiea gatewayPrimary authIdP / directorySAML, OIDC, LDAPMFA challengeOTP, passkey, SMS…Authenticated sessionConnection tokenTargetSSH, RDP, DB, K8s
Operator

Web console, workbench, or SSH client.

Gateway

Primary auth and optional MFA before any target connection.

MFA

Second factor when global or per-user policy requires it.

What it covers

MFA where privileged access starts

Legacy protocols do not natively support modern second factors. Because Ixiea brokers those sessions, MFA at gateway login covers SSH shells, graphical RDP, and database clients without changing targets.

01
SSH MFA at the gateway

Direct SSH connections complete MFA through a keyboard-interactive challenge at the gateway — before a session is brokered to the target. No agent on the host, no change to sshd.

02
Web console and SSO

Password and federated logins can require a second factor before the workbench loads. Third-party login MFA lets you enforce Ixiea factors even when primary auth came from your IdP.

03
Enrollment and reset

Users bind OTP secrets, passkeys, or other factors from their profile. Admins can reset MFA when devices are lost. Brute-force protection blocks repeated failed attempts.

04
Sensitive console actions

Viewing account secrets in the console can require a fresh MFA verification within a configurable TTL — so a stale browser tab does not expose credentials without re-proofing.

05
Global and per-user policy

Turn MFA off, require it for everyone, or require it for administrators only. Individual users can be enabled or force-enabled regardless of the global default.

When MFA applies

Clear triggers — no hidden risk engine

Ixiea MFA is policy-driven at known checkpoints: login, SSH gateway auth, and sensitive console actions. Command filtering and login approvals are separate controls — see command control and authorization.

TriggerExampleResponse
Web loginUsername and password, or QR codeMFA challenge when global or per-user policy requires it; optional MFA on the login page for GDPR-aligned deployments.
Federated loginSAML, OIDC, OAuth, CAS, or LDAP SSOOptional Ixiea MFA after IdP sign-in when third-party login MFA is enabled — independent of what the IdP already enforced.
SSH connectssh user@ixiea-gatewayKeyboard-interactive MFA prompt at gateway authentication before the brokered session opens.
View account secretReveal password in the asset account panelMFA re-confirmation within the configured verify TTL; otherwise the action is blocked.
High-risk commandDROP TABLE, rm -rf, privileged systemctlCommand filter ACLs deny or route to an approver ticket — not an inline MFA prompt. Pair with login MFA and recording for defense in depth.

Supported factors

Pick the methods your operators can actually use

Enable the factor backends that match your SMS gateway, RADIUS deployment, and security policy. Passkeys and OTP are the usual starting point; RADIUS and custom modules extend coverage for regulated environments.

Device compliance and geolocation policies belong in your IdP or endpoint stack. Ixiea honours federated primary auth and enforces its own second factor at the gateway when configured.

Factor types

  • OTP / TOTP

    Authenticator apps (RFC 6238). Most common enrollment path.

  • Passkey

    WebAuthn platform or security keys. Phishing-resistant when bound to your domain.

  • SMS

    One-time codes via configured SMS gateway.

  • Email

    Optional email OTP when SECURITY_MFA_BY_EMAIL is enabled.

  • RADIUS OTP

    Delegate the second factor to an existing RADIUS MFA service.

  • Face recognition

    Biometric verification when face recognition is enabled in your deployment.

Federation

Stack Ixiea MFA on your IdP

Most teams already enforce MFA in Okta, Entra ID, or another identity provider. Ixiea can rely on that primary authentication and still require a native second factor for privileged paths — especially SSH gateway login and secret viewing — where the IdP has no visibility.

Disabling an account in your directory removes gateway access immediately. MFA enrollment and reset stay auditable in Ixiea session logs.

Integration points

  • SAML 2.0, OIDC, OAuth 2.0, and CAS for federated primary authentication
  • LDAP and Active Directory for directory-backed login
  • Third-party login MFA to require Ixiea factors after SSO
  • Custom MFA module hook for organisation-specific factor backends

See it in your estate

Walk through web login, SSH MFA, and secret viewing

We will configure global MFA policy, enroll a test factor, and connect through SSH with keyboard-interactive verification.

Book a walkthroughRead the admin guide