SSO & MFA for the Remote Access Portal

Building a secure remote access portal with SSO and MFA? WZ-IT builds sovereign remote-maintenance platforms with central identity, MFA and audit. See our remote management platforms

A remote access portal should not secure each service with its own login. It should route every access through a central identity: a Single Sign-On (SSO) via SAML 2.0 or OpenID Connect, combined with enforced Multi-Factor Authentication (MFA). That gives you exactly one place to enforce authentication, MFA, context rules and the removal of access. It eliminates password sprawl, makes every access auditable, and meets the requirements of NIS2 and IEC 62443. In practice, open-source identity providers such as Authentik or Keycloak deliver this identity layer fully self-hosted.

Table of contents

• Why central identity beats per-service logins
• SSO protocols: SAML 2.0 and OIDC
• Identity providers: Authentik and Keycloak
• MFA methods: TOTP, WebAuthn/passkeys, push
• Conditional access: context-based decisions
• Provisioning, deprovisioning and supplier accounts
• SSO/MFA as the identity layer for ZTNA
• SSO and MFA at WZ-IT

---

Why central identity beats per-service logins

When every HMI, server and web tool ships its own login, you end up with an uncontrollable number of accounts and passwords. Nobody reliably knows who can reach what, MFA is at best partially enabled, and when a contractor leaves, scattered accounts linger. Those forgotten logins are a classic breach vector.

A central identity reverses this. There is one authoritative identity source (the identity provider, IdP) that all services connect to. The benefits:

• One enforcement point: password policy, MFA requirement and context rules apply centrally to all services, not reconfigured per tool.
• Instant deprovisioning: disabling an account in the IdP ends access to every connected service at once.
• Accountability: every login flows through the same point and lands in the audit trail (see RBAC and audit for remote access).
• Smaller attack surface: no more local service passwords that get copied, shared or forgotten.

SSO protocols: SAML 2.0 and OIDC

SSO means a user authenticates once with the IdP, and services then trust them without asking for a password again. Two open standards define how the IdP and the service communicate:

• SAML 2.0: an XML-based OASIS standard from 2005, widely used in traditional enterprise software. The IdP issues a signed assertion that the service (service provider) verifies.
• OpenID Connect (OIDC): the modern identity layer on top of OAuth 2.0. OIDC uses JSON/JWT, fits web apps, APIs and mobile clients better, and is today's first choice for new integrations.

In practice it is not either-or: a capable IdP speaks both, so a legacy application can connect via SAML and a new one via OIDC, both behind the same central identity.

Identity providers: Authentik and Keycloak

The IdP is the heart of the setup. Two open-source, self-hostable options have become standard:

• Keycloak: a mature, enterprise-grade project (CNCF/Red Hat). The current line is version 26.6 (June 2026). Keycloak supports SAML 2.0, OIDC/OAuth 2.0, WebAuthn, TOTP and step-up authentication via authentication flows.
• Authentik: lean, modern and highly configurable through flows and policies. The current line is 2026.5 (on a three-month cycle since May 2026). Authentik supports SAML, OIDC/OAuth 2.0, a SCIM provider, WebAuthn/passkeys, TOTP and push.

Both run entirely on your own infrastructure in the EU. Control plane, keys and audit data stay in your hands instead of living with an external identity service.

MFA methods: TOTP, WebAuthn/passkeys, push

MFA adds a second factor to the password. What matters is phishing resistance: methods based on WebAuthn/FIDO2 bind the cryptographic key to the domain, so a fake login page cannot capture the factor. WebAuthn has been established since Level 2 (W3C Recommendation, April 2021); Level 3 has been at Candidate Recommendation since January 2026 (updated snapshot May 2026).

The authoritative reference is NIST SP 800-63B-4 (final since July 2025): at assurance level AAL2 a phishing-resistant option must be offered, and AAL3 requires phishing-resistant hardware authenticators. Practical recommendation: passkeys as the default, TOTP as a fallback, and WebAuthn mandatory for privileged roles (administrators, critical machines).

Conditional access: context-based decisions

Strong authentication is the baseline, but not every access carries the same risk. With conditional access (context-based access) the IdP factors additional signals into the decision:

• Device posture: managed device, current OS, client version.
• Network and location: source IP, country, known site.
• Time and risk: unusual hours, new devices, suspicious patterns.

The outcome is either direct access, a step-up authentication (an extra factor for sensitive actions) or a denial. Keycloak expresses this through ACR/LoA levels and conditional authentication flows; Authentik through policies and expression policies evaluated inside the flow. Viewing a dashboard then carries a different bar than performing a control action on a machine.

Provisioning, deprovisioning and supplier accounts

Identities have a lifecycle: create, change, revoke. Managed by hand, mistakes creep in, especially at revocation. The open standard SCIM (RFC 7643/7644) automates this: the source of truth (e.g. HR or a directory) automatically creates, updates and deactivates accounts in the IdP.

For supplier and contractor accounts, time-limiting is central. External parties get no permanent account but access with an expiry date, ideally as just-in-time access: the grant only applies to a defined maintenance window and a specific machine, then expires automatically. This avoids orphaned standing privileges, a frequent breach vector. The role and permission logic behind it is covered in RBAC and audit for remote access.

Clean deprovisioning is the biggest security win of central identity: when someone leaves, disabling the account in the IdP instantly ends access to every connected service, instead of cleaning up each tool one by one.

SSO/MFA as the identity layer for ZTNA

SSO and MFA are the "verify" component of Zero Trust Network Access (ZTNA). Zero Trust re-evaluates every request against identity, device posture and context before a connection is established. The IdP supplies the authoritative identity: only once SSO login, MFA and conditional-access conditions are satisfied does the policy broker release the individual resource, never the whole network. Without strong, central identity, any Zero Trust model stays piecemeal.

NIS2: Article 21 of the NIS2 Directive and Germany's Section 30 BSIG explicitly name multi-factor authentication and access control policies as minimum measures. Germany's NIS2 implementation law has been in force since December 2025. A central SSO that enforces MFA is the auditable way to meet this obligation for remote access. This article is general information and not legal advice.

SSO and MFA at WZ-IT

In our sovereign remote-maintenance platforms, identity is never an afterthought but the central control point. We deploy a self-hosted IdP (Authentik or Keycloak) as the authoritative identity source, connect every service via OIDC or SAML, enforce MFA with passkeys, and add conditional access for privileged operations. Supplier accounts are time-limited and provisioned and deprovisioned cleanly via SCIM. Every login lands in a tamper-evident audit trail.

We run this approach in production: at ABCO Water Systems in Australia for machine and HMI access across distributed sites, and at nextGYM in Germany for a rolled-out IoT device fleet. We are happy to handle design, build and operations end to end as part of our remote management platforms.

Related guides

• RBAC and audit for remote access - roles, least privilege and tamper-evident logs
• What is ZTNA? - Zero Trust Network Access and the role of identity
• NIS2-compliant remote access - regulatory context
• Authentik expertise and Keycloak expertise

Building a secure remote access portal with central identity, MFA and audit? Get in touch or explore our remote management platforms.