Blog Feed
Azure MFA NPS Extension: Limitations, Costs & On-Prem Alternatives (2026)
The Azure MFA NPS Extension has been the go-to answer for adding a second factor to Microsoft NPS and securing VPN, Wi-Fi, and other network access protected by RADIUS authentication for years. It’s free (if you have the right license), it installs in under an hour, and it works. Until it doesn’t — and when it doesn’t, the failure mode is usually a structural one, not a configuration problem you can fix with a registry tweak. This article is for administrators who are already running the NPS Extension and have started hitting its ceilings: cloud dependencies that don’t fit your architecture, hardware token requirements that Azure can’t satisfy, or an air-gapped segment that simply can’t phone home to Entra ID. We’ll cover what the extension actually does, where it breaks down in practice, and what an on-premises RADIUS proxy alternative looks like side by side. TL;DR / Quick Answer The Azure MFA NPS Extension is a Microsoft-provided plugin for Windows Server NPS that adds a second authentication factor to RADIUS-authenticated services — VPN, Wi-Fi 802.1X, and dial-up. It works by intercepting successful primary authentication and triggering an Entra ID (formerly Azure AD) MFA challenge before returning an Access-Accept. Four structural limitations define where it stops working: Cloud dependency — every authentication event requires a live connection to Entra ID. No internet, no MFA, no access. No real hardware token support — OATH TOTP hardware tokens require Entra ID P1/P2 licensing and have significant enrollment constraints. Limited MFA methods — Microsoft Authenticator push and OATH TOTP only. No SMS, no email OTP, no chatbot. On-premises AD requires Entra ID Connect — pure on-prem AD deployments need a sync layer to Azure before the extension functions at all. If any of those four points describes your environment, an on-premises RADIUS proxy may be a better fit. What the Azure MFA NPS Extension Does Network Policy Server (NPS) is the built-in RADIUS server in Windows Server. It handles authentication for a wide range of services: RRAS-based VPN, Wi-Fi 802.1X via wireless access points, wired 802.1X, and dial-up. In most enterprise Windows environments, NPS is deeply embedded — it carries years of connection request policies, remote access policies, and accounting configuration. The NPS Extension slots into this existing infrastructure as a post-authentication plugin. When a user’s password is validated successfully against Active Directory, the extension intercepts the authentication flow and calls out to Entra ID to trigger an MFA challenge. If the user approves the push notification or enters their OATH TOTP code, the extension signals NPS to return an Access-Accept. If MFA fails, the connection is denied. From an architecture standpoint, this is elegant: you don’t change how NPS works, you don’t reconfigure your VPN gateway, and you don’t need a new RADIUS server. The extension adds one step to an existing flow. The practical appeal is also clear. For organizations already in the Microsoft ecosystem — Entra ID licenses in place, Microsoft Authenticator rolled out to users, Entra ID Connect syncing on-prem AD — the extension is a fast, low-cost path to NPS MFA. Installation takes minutes, and for straightforward environments it works exactly as advertised. The problems emerge at the edges of that “straightforward environment” assumption. 1. User Starts VPN or Wi-Fi authentication Username + password submitted ▼ 2. VPN...
read moreHost-Level vs Network-Level MFA: Credential Provider (RDP/Windows Logon) vs RADIUS Proxy (VPN/Wi-Fi)
Managing remote access security requires a decision most teams avoid until something goes wrong: where exactly should MFA be enforced? At the network edge, or on the host itself? The answer isn’t binary — but getting the layer wrong means either leaving critical servers exposed after a perimeter breach, or blocking legitimate administrators from getting in when the network stack misbehaves. This article breaks down the two enforcement models, what each one actually protects, and when using both together is the right call. TL;DR / Quick Answer There are two distinct layers where MFA can be enforced in a Windows environment: Host-level MFA (Windows Credential Provider) intercepts authentication directly on the machine — at the Windows logon screen or during an RDP session. It protects the host regardless of how the user reached it. Works with NLA. Supports offline mode. Best for servers, jump hosts, and workstations. Network-level MFA (RADIUS proxy) enforces a second factor at the network edge for VPN, VDI, and other RADIUS-authenticated services before users reach internal resources. No agent required on individual hosts. Best for remote access and network perimeter. Strategy: most enterprise environments need both. Network-level MFA stops attackers at the perimeter; host-level MFA stops lateral movement after a perimeter breach. The Two Enforcement Layers The fundamental difference between host-level and network-level MFA comes down to where in the access chain the second factor is checked. Host-level MFA sits inside the operating system. A Credential Provider agent installed on a Windows machine intercepts the logon process — whether that’s a local console login or an inbound RDP session. The MFA check happens before the Windows shell loads, meaning an attacker who reaches the login screen still can’t get in without the second factor. Network-level MFA sits in front of your infrastructure. A RADIUS proxy receives authentication requests from a RADIUS-enabled service or device, validates the user’s password against Active Directory or LDAP, and then issues a second-factor challenge before returning an Access-Accept to the network device. The host never sees the unauthenticated connection attempt. Neither layer is a substitute for the other. A network-level MFA deployment alone does not protect Windows logon or direct RDP authentication on the target host. If an attacker reaches the login screen through another path, host-level MFA remains the final control preventing unauthorized access. And according to Mandiant’s 2026 threat intelligence report (covering IR cases from 2025), attackers used RDP for lateral movement in approximately 85% of intrusions after gaining initial access. Stopping them at the VPN gateway doesn’t help if they got in through a different path. Host-Level MFA: The Credential Provider Approach Host-level MFA integrates directly into the Windows Authentication Architecture. The Protectimus Winlogon component installs a custom Credential Provider on each Windows machine, intercepting the logon process immediately after primary credential submission and before the session is established. Technical Implementation When a user attempts to log in — via RDP or a physical console — the Credential Provider agent intervenes. It pauses the Windows logon sequence until MFA verification completes. If the user provides a valid OTP or approves a push notification, the agent releases the handshake and the Windows shell loads. If MFA fails or times out, access is denied regardless of whether the password was correct. This happens at a level below the Windows...
read moreProtectimus vs RSA: MFA Comparison of Features, Pricing, and Integrations
When looking for a reliable multi-factor authentication (MFA) solution, it’s easy to get lost in the variety of options available on the market. To help navigate these choices, we continue our comparison series by examining how Protectimus stacks up against other well-known authentication vendors. In this article, we compare Protectimus and RSA. Both companies offer strong authentication solutions, but they approach the problem from different angles. RSA is positioned more broadly as an enterprise authentication and access platform with a strong passwordless and identity-centric direction, while Protectimus focuses on practical MFA flexibility built around open OATH standards, broad deployment choice, and straightforward implementation. This distinction matters because the right choice often depends less on which vendor is “better” in absolute terms and more on what an organization is trying to achieve. Companies building a broader identity, passwordless, and access ecosystem may lean toward RSA. Companies looking for flexible, standards-based MFA with strong OTP coverage, deployment control, and lower operational complexity may find Protectimus a stronger fit. Protectimus is based on open OATH standards such as HOTP, TOTP, and OCRA, which can simplify integration, migration, and long-term interoperability. RSA, in contrast, offers a broader enterprise platform with stronger emphasis on phishing-resistant passwordless authentication, federation, and identity workflows across cloud, hybrid, and legacy environments. Prefer short reads? See the comparison table below! 1. Server-Side Component Key Difference: RSA offers both cloud and on-premises deployment options as part of a broader enterprise authentication and access portfolio. Protectimus offers both a fully cloud-based MFA service and a comprehensive on-premise MFA platform built around the same practical OATH-based approach. RSA RSA provides cloud and on-premises authentication solutions for enterprise environments. Its current offering is broader than traditional MFA alone and includes passwordless authentication, SSO, adaptive access, help desk verification, and additional identity-related workflows. This makes RSA attractive for large organizations with complex authentication requirements, especially those modernizing workforce access across cloud and legacy environments. Its broader scope can be a major advantage for enterprises standardizing access controls across many systems, although it may be more than some companies need if their main goal is to deploy flexible MFA quickly and with lower complexity. Protectimus Protectimus offers clients a choice between a Cloud MFA Service and a Self-Hosted On-Premise MFA Platform. This flexibility suits both organizations that want a managed cloud service and companies that need to keep the authentication system inside their own infrastructure. One of the main advantages of Protectimus is operational simplicity. Both deployment models follow the same practical MFA logic and the same standards-based foundation, which can make implementation, customization, and long-term administration more straightforward for teams that want strong authentication without adopting a broader IAM stack. Available in cloud yes yes Available on-premises yes yes 2. Features Key Difference: RSA focuses more strongly on passwordless access, SSO, adaptive access, and broader enterprise authentication workflows. Protectimus provides practical MFA flexibility, SSPR, transaction signing, broad token support, and strong deployment control for mixed cloud and on-premise environments. RSA Note: Many advanced RSA capabilities depend on the product tier and the broader access package selected. Self-Service for Users. Users can enroll and manage authentication methods independently. Single Sign-On (SSO). Supports centralized access to enterprise applications. Adaptive Access. Higher-tier plans support contextual and adaptive access policies. Help Desk Identity Verification. RSA offers verification workflows...
read moreHow Secure Is Two-Factor Authentication: 2FA Attacks and How to Prevent Them
Two-factor authentication security has improved dramatically in recent years, but attackers continue developing new ways to bypass 2FA protections. Two-factor authentication (2FA or MFA) is one of the most widely used security mechanisms for protecting online accounts and corporate systems. By adding an additional verification step to the login process, it significantly reduces the risk of unauthorized access. However, attackers constantly evolve their techniques. Instead of trying to break encryption or authentication algorithms, they focus on weaknesses around the authentication process itself. In this article, we examine how secure two-factor authentication really is, what modern attacks target 2FA systems, and how organizations can effectively protect themselves. Two-factor authentication (2FA) is a security method that requires two independent verification factors before granting access to an account or system. Key Takeaways Two-factor authentication significantly improves security compared to password-only login. Modern attacks against 2FA include phishing proxy attacks, MFA fatigue, and SIM swapping. Most successful attacks target users and workflows rather than authentication algorithms. Hardware tokens and transaction signing (CWYS) provide stronger protection than SMS authentication. Is Two-Factor Authentication Really Secure? Compared to password-only authentication, two-factor authentication dramatically improves account security. Authentication typically combines: something you know — a password or PIN something you have — for example a smartphone or hardware OTP token something you are — biometric identifiers This layered approach makes unauthorized access significantly more difficult. Even if an attacker steals a password, they still need the second authentication factor. That said, 2FA is not magic. Its real-world effectiveness depends on the authentication method you choose, how recovery is configured, and whether users can recognize phishing and social engineering attempts. Why Attackers Target Two-Factor Authentication Attackers rarely try to break authentication algorithms directly. Instead, they exploit the surrounding process. phishing users and capturing credentials in real time; intercepting or relaying authentication traffic; abusing weak recovery procedures; overwhelming users with repeated approval requests; downgrading authentication to weaker channels such as SMS. This is why strong 2FA is not just about adding a second factor. It is also about choosing phishing-resistant methods, securing recovery flows, and limiting opportunities for user error. Common Ways Hackers Bypass Two-Factor Authentication 1. Phishing proxy attacks Modern phishing campaigns often use phishing proxy tools that relay authentication traffic between the victim and the legitimate service in real time. The victim enters credentials and OTP codes on a fake login page. The proxy forwards them instantly to the real service and logs in as the victim. This is one of the clearest examples of why basic OTP alone is not always enough against sophisticated phishing campaigns. 2. MFA fatigue and push bombing In MFA fatigue attacks, criminals repeatedly trigger login approval requests until the victim accidentally approves one of them. This technique relies on pressure, confusion, and the user’s desire to stop the flood of notifications. 3. Social engineering Social engineering attackers impersonate trusted entities such as banks, IT support teams, or service providers to trick victims into revealing authentication codes or approving malicious requests. Even strong authentication can be weakened if users are persuaded to cooperate with the attacker. 4. Man-in-the-middle and man-in-the-browser attacks Man-in-the-middle attacks intercept communication between users and servers. In man-in-the-browser attacks, malware manipulates transactions directly inside the browser session. In both cases, the user may see what appears to be a...
read moreWhat Is Two-Factor Authentication (2FA) and How Does It Work?
Two-factor authentication (2FA) is one of the most effective ways to protect accounts from phishing, password leaks, and unauthorized access. Almost every Internet user has encountered two-factor authentication (2FA) at least once — when logging into online banking, corporate systems, email accounts, cloud services, or even social media. However, not everyone clearly understands how it actually works. Two-factor authentication adds an additional security layer to a standard login and password. Instead of relying on just one piece of information, the system verifies the user using two independent factors. This significantly reduces the risk of unauthorized access. Let’s take a closer look at how 2FA works and where modern solutions such as Protectimus fit into this process. What Is Two-Factor Authentication (2FA)? Two-factor authentication (2FA) is a security mechanism that requires users to verify their identity using two different authentication factors before gaining access to an account or system. Typically, these factors include: a password or PIN (something the user knows) a device that generates a one-time password or receives a login confirmation (something the user has) This additional verification step significantly reduces the risk of unauthorized access, even if the password becomes compromised. The First Factor – Something You Know The first authentication factor is usually the standard password used to log in to a website or system. This is known as a knowledge factor because it relies on information that only the user should know. Other examples of knowledge factors include: PIN codes security questions passphrases However, passwords alone are not reliable protection. They can be: stolen in phishing attacks leaked in database breaches guessed or reused across multiple services This is why modern security systems combine passwords with an additional authentication factor. You can also read our guide What Is Two-Factor Authentication? for a broader overview. The Three Authentication Factors Authentication mechanisms are traditionally divided into three categories: Something you know — password or PIN Something you have — token, smartphone, smart card Something you are — biometric characteristics Two-factor authentication combines any two of these factors. What Is the Difference Between 2FA and MFA? Two-factor authentication (2FA) is a subset of multi-factor authentication (MFA). The difference is simple: 2FA uses exactly two authentication factors. MFA can use two or more authentication factors. Most modern security systems, including the Protectimus MFA platform, support multiple authentication methods and allow administrators to configure flexible authentication policies. How 2FA Works – A Simple Example Typical two-factor authentication process: User enters login and passwordFirst authentication factor — something the user knows. The system requests a one-time password (OTP)The authentication server generates or requests a temporary verification code. User enters the OTP or confirms loginThe code is generated by a hardware token, authenticator app, or delivered via chatbot, SMS, or email. Access is grantedIf both factors are valid, the user successfully logs in. Modern authentication platforms like Protectimus MFA manage this entire process — generating OTP codes, delivering them to users, and verifying them during authentication. The Second Factor – Something You Have The most common second factor today is a device that generates or receives one-time passwords (OTP). This can include: hardware OTP tokens mobile authenticator apps SMS or email OTP delivery push authentication messenger chatbot OTP delivery The Protectimus MFA platform supports multiple authentication methods: Hardware OTP tokens — dedicated...
read moreMFA Fatigue Attacks: How They Work, Risks, and Prevention
Multi-factor authentication (MFA) is a well-known and effective measure of protecting access to user accounts. MFA helps to reduce the number of attacks associated with stolen login data. Due to the use of two or more different authentication factors, it’s almost impossible to access the account even if an attacker has the user’s login and password. However, attackers constantly find new ways to bypass two-factor authentication, often exploiting human factors. One of such new growing threats based on human factor is the MFA fatigue attack. Let’s explore what an MFA fatigue attack is and how to counter it. What Is an MFA Fatigue Attack? An MFA fatigue attack is a type of social engineering technique in which an attacker repeatedly triggers authentication requests, typically through push-based MFA, in order to overwhelm the user. MFA fatigue attacks are also called MFA bombing, MFA push bombing, MFA prompt bombing, or MFA push spam. The main goal of this type of attack is not to steal a one-time password, but to make the user approve a login request themselves. In this scenario, the attacker already has valid credentials (a username and password). Instead of attempting to bypass MFA technically, they rely on persistence, timing, and psychological pressure to gain access. This makes MFA fatigue fundamentally different from classic MFA bypass techniques such as phishing, brute force, keyloggers, man-in-the-middle, or SMS interception. How MFA Fatigue Attacks Work? A typical step-by-step breakdown of an MFA fatigue attack looks like this: Credential compromise. The attacker obtains a valid username and password, often through techniques such as phishing, credential leaks, or malware. Repeated login attempts. The attacker initiates multiple login attempts that trigger MFA push notifications. Notification overload. The victim receives dozens of unexpected approval requests within a short period of time. Accidental approval. Due to fatigue, distraction, or confusion, the user taps “Approve” or “Yes” just to stop the notifications. Successful access. The attacker gains legitimate access, with logs showing a valid MFA-approved session. Why Push-Based MFA Is Vulnerable to MFA Fatigue? Push-based MFA is popular because of its convenience. A single tap is often all that’s required to complete authentication. However, this low friction also introduces risk. Push notifications often: Provide little context about the login attempt; Can be triggered repeatedly without meaningful limits; Rely entirely on user judgment at the moment of approval. This risk can be partially mitigated by using CWYS (Confirm What You See) feature, a feature introduced by Protectimus.With this feature the push notification displays contextual details about the action being approved, making accidental or automated approvals far less likely. Alternatively, the issue can be further reduced by moving away from push-based authentication altogether and adopting alternative authentication methods, which we will discuss later. Is MFA Fatigue an MFA Bypass or User Error? From a technical perspective, MFA fatigue is not a cryptographic failure. MFA works exactly as designed – the system sends a request, and the user approves it. However, from a security standpoint, MFA fatigue represents a practical MFA bypass. The attacker gains access without breaking MFA, simply by manipulating the approval process. Because the login is successfully approved, such attacks are difficult to detect using traditional security logs. The session appears legitimate, even though it was initiated under malicious pressure. The Human Factor Behind MFA Fatigue Attacks...
read moreLouvre Heist: From ‘Louvre’ as a Password to a Global Lesson in MFA
On October 19, 2025, the world watched in shock as the Louvre fell victim to a lightning-fast theft. In just a few minutes, masked intruders broke into the Galerie d’Apollon, smashed display cases, and made off with priceless jewels of the French crown — treasures worth around €88 million. By the time the alarm went off, the Louvre heist thieves had already disappeared into the Paris morning, leaving the museum and its staff reeling. Much of how this happened comes down to one thing: cybersecurity that wasn’t taken seriously. For years, the Louvre hadn’t updated its software, relied on a single, painfully simple password — literally “Louvre” — and didn’t use multi-factor authentication (MFA) on critical systems. Outdated operating systems, poorly monitored networks, and loosely controlled administrative access all created openings that attackers could exploit. In short, the digital side of the museum’s security was easy to bypass, and that weakness made a bold physical robbery possible. After the heist, Protectimus stepped in and offered the Louvre its MFA services free of charge, ready to help ensure that something like this can’t happen again. Adding multi-factor authentication could have stopped the intruders before they ever got close to the treasures, even if they had the password. In this article, we’ll take a closer look at how the Louvre heist unfolded, the cybersecurity gaps it revealed, and the lessons the Louvre and other institutions around the world should learn. We’ll also show how multi-factor authentication could make a real difference and how Protectimus’ solutions can help protect against similar attacks in the future. 1. How the Louvre Heist Happened October 19, 2025, around 5:30 AM A group of unknown thieves (likely 3–4 people) arrives at the Louvre in a van equipped with a lift, disguised as maintenance workers. They use the lift to reach a window on the second floor — at the Galerie d’Apollon, where the French crown jewels were displayed, including diamonds and precious stones collected by Louis XIV–XVI. 5:36 – 5:43 AM The intruders break the window, enter the gallery, smash multiple display cases, and steal eight items valued at over $100 million. Among the stolen treasures are Queen Marie-Therese’s earrings, the “Le Miroir du Roi” diamond, and several ornate brooches. The entire operation takes less than 8 minutes. Security cameras partially capture shadowy movements, but no clear images of the thieves. Around 6:00 AM Alarms are triggered with delay, and security arrives after the thieves have already disappeared. Evidence suggests they left via the same route, leaving no DNA or fingerprints behind. Following Days Police and the ANSSI cyber unit discover that the museum’s security systems were extremely outdated.Management acknowledges the existence of structural deficiencies and resigns. France’s Minister of Culture publicly states: “We have underestimated digital security risks for years.” | Read also: How to Protect Your Business Against Cyber Crime 2. A Decade of Cybersecurity Neglect For years, the Louvre had been operating with a serious lack of attention to its digital security. Many of its systems were old, unsupported, and vulnerable. Some servers ran on Windows Server 2003 or even Windows XP, leaving them open to known attacks that modern patches would have blocked. Critical systems like video surveillance and access control were protected by extremely weak passwords — literally “LOUVRE” or “THALES”...
read morePasswordless Authentication with Protectimus DSPA: How it Works
Protectimus Dynamic Strong Password Authentication (DSPA) now supports passwordless authentication based entirely on one-time passwords (OTPs). Users authenticate using temporary dynamic credentials generated with the TOTP algorithm, eliminating the risks associated with static passwords while maintaining a secure and user-friendly login experience. In this article, we explain how OTP-only authentication works in Protectimus DSPA, how it integrates with Active Directory and other directory-based environments, and where passwordless authentication can be effectively applied. Get Started with Protectimus DSPA How Protectimus DSPA Works Protectimus Dynamic Strong Password Authentication (DSPA) integrates directly with user directories such as Microsoft Active Directory, LDAP, and other supported databases, replacing traditional static passwords with dynamic one-time passwords (OTPs) generated using the TOTP algorithm. The administrator defines the OTP rotation interval, which must be a multiple of 30 seconds. As a result, users authenticate using temporary time-based OTP credentials instead of permanent static passwords. Administrators can define the OTP rotation interval, starting from 30 seconds with configurable step-based increases. Rotation policies can be configured individually for different users and groups. In practice, users authenticate using temporary OTP credentials instead of permanent static passwords. OTPs can be generated in the Protectimus SMART authenticator app or delivered through Protectimus BOT chatbots in Telegram, Viber, or Facebook Messenger. Access to the app or chatbot can also be additionally protected with a PIN code or biometrics for enhanced security. | Read also: Two-factor authentication for Windows 7, 8, 10 How Passwordless Authentication Works With the “Allow Passwordless” option turned on, users log in only with one-time passwords (OTPs). Static passwords are no longer part of the process. Instead of using a permanent password along with an OTP, authentication depends entirely on dynamic codes that change with each login attempt. This method makes the user experience simpler while also greatly improving security. Weak, reused, or stolen passwords, which are a common cause of breaches, are completely eliminated. At the same time, OTPs make sure that every login is confirmed with a unique, time-limited credential. Administrators can choose how widely to apply this setting. Passwordless authentication can be enabled for all accounts to create a consistent login process across the organization, or it can be activated only for specific users and systems where minimizing password risks is particularly important. Advantages of Passwordless Authentication Mode Passwordless authentication with Protectimus DSPA brings a range of benefits for both users and administrators: Simplified User Experience. Users don’t need to remember complex passwords or update them regularly. Logging in with a single OTP makes access faster and easier while still keeping accounts secure. Reduced IT Overhead. Fewer password-related support requests and resets mean IT teams can spend less time managing credentials and focus on other priorities, all while maintaining strong security. Lower Password Risks. Removing static passwords eliminates the threat of weak, reused, or stolen credentials. Every login relies on a time-based one-time password (OTP) that constantly changes and can’t be reused. Flexible Deployment. Administrators can enable passwordless authentication for everyone or only for specific users and groups, making it easy to tailor security policies to the organization’s needs. In short, passwordless authentication simplifies the login process for users without compromising security, providing organizations with a flexible way to protect their systems without relying on static passwords. | Read also: Authenticator App Protectimus SMART Updated – Now...
read moreProtectimus vs ESET: Which Two-Factor Authentication Fits Your Needs?
When searching for a reliable multi-factor authentication (MFA) solution, the sheer number of products on the market can be overwhelming. To simplify your decision-making process, we’ve created a series of comparison guides showing how the Protectimus MFA platform compares to other leading providers. In this article, we’ll focus on Protectimus and ESET. Both companies deliver robust two-factor authentication (2FA) solutions, but they differ in deployment models, integration flexibility, authentication methods, and licensing. Below, we’ll examine how they compare in terms of server-side deployment, supported technologies, core features, authentication options, and pricing. Prefer a quick overview? Check the comparison table below! 1. Server-Side Component Key Difference: ESET Secure Authentication is primarily a server software installed on-premises or in a private cloud, with optional mobile/cloud services for push notifications. Protectimus provides both cloud-based and fully featured on-premise MFA platforms. ESET Secure Authentication ESET Secure Authentication (ESA) is designed mainly as an on-premises 2FA solution. The core authentication server runs inside the organization’s infrastructure — either on a Windows Server or in a virtualized/private cloud environment. This setup gives businesses full control over configuration and user data, which is ideal for environments with strict privacy or regulatory demands. ESA also offers a lightweight cloud component that enables features like push notifications, SMS delivery, and licensing synchronization. However, this is an add-on, not a complete SaaS platform — the local ESA server remains the backbone of the deployment. The ESA Management Console allows administrators to: Set up policies and assign second-factor methods to users. Review logs and audit authentication attempts. Integrate with Active Directory, Microsoft 365, VPN, and other applications via ESA plugins. Manage mobile apps, SMS gateways, or hardware tokens for OTP delivery. While ESA can function in hybrid mode (on-prem plus optional cloud services), it doesn’t provide a standalone full SaaS model. Organizations must maintain the ESA server infrastructure for core MFA services. Protectimus Protectimus lets customers choose between a Cloud MFA Service or a Self-Hosted On-Premises Platform. This versatility makes it suitable for businesses ranging from startups to enterprises and government agencies with strict compliance requirements. Protectimus Cloud Service The cloud edition of Protectimus MFA is a fully managed service hosted in secure, distributed data centers. It enables organizations to: Integrate MFA quickly without deploying local servers. Reduce administrative overhead and maintenance costs. Scale easily as users or protected apps increase. Access a rich web console for reports, logs, and configuration. All OTP validation, policy enforcement, and access rules are handled by Protectimus’ secure backend. Integration is straightforward through APIs, SDKs, and ready-to-use plugins (LDAP, Windows, RADIUS, ADFS, Azure AD, OWA, Citrix, VPN, and more). Protectimus On-Premise Platform For customers that need maximum control, Protectimus offers a dedicated on-premise platform. It’s installed in the client’s own environment, giving them the ability to: Keep all authentication data inside their perimeter. Operate in isolated or offline environments. Meet GDPR, ISO 27001, or local security standards. The on-premise version mirrors the cloud feature set, including the Admin Console, support for every token type, APIs, SDKs, and optional perpetual licensing. Organizations can move between cloud and self-hosted models, or run both in hybrid mode during migration. Available in cloudlimited (for push/SMS)yesAvailable on-premisesyesyes 2. Features Key Difference: ESET Secure Authentication focuses on core MFA functions for Windows, VPN, and web services, with straightforward management tools....
read moreProtectimus vs Rublon: A Detailed Comparison of Two Multi-Factor Authentication Solutions
When looking for a reliable multi-factor authentication (MFA) solution, it’s easy to get lost in the variety of options available on the market. To help you navigate these choices, we’ve launched a series of comparison articles that examine how the Protectimus MFA platform stacks up against other prominent providers. In this article, we’ll take a closer look at Protectimus and Rublon. Both companies provide comprehensive two-factor authentication (2FA) solutions, but differ significantly in deployment options, features, provided authentication methods, and customization options. We’ll walk you through the key differences in server-side deployment, supported technologies, core features, authentication methods, and pricing. Prefer short reads? See the comparison table below! 1. Server-Side Component Key Difference: Rublon is a cloud-based solution. Protectimus offers both fully cloud-based and comprehensive on-premise MFA server deployment options. Rublon Rublon is a cloud-based two-factor authentication solution. This means Rublon hosts and manages all authentication servers in its infrastructure. When an organization activates Rublon MFA, the cloud platform handles all authentication logic, configuration, policies, and event logs. There is no option to deploy the authentication server on-premise — this makes Rublon easier to set up and manage, but limits its applicability in environments with strict data residency, privacy, or regulatory requirements. The Rublon Admin Console is the central control point. From there, administrators can: Configure MFA rules and policies (e.g. IP allowlisting, adaptive access conditions). View authentication events and audit logs. Assign applications for protection, such as VPN, Microsoft 365, RDP, and ADFS. Add or remove users. Deploy Rublon’s connectors to protect systems and integrate with the Rublon cloud backend. Users are authenticated through connectors or agents (e.g., Rublon Windows Logon & RDP agent, VPN plugin, SSO connector), which communicate with the Rublon cloud to verify credentials and deliver second factors like push notifications or TOTP challenges. These connectors are lightweight components that do not operate as full authentication servers, but rather serve as a bridge between local applications and the Rublon cloud. There is no local fallback option — if the Rublon cloud service is unreachable (e.g., due to internet outage), MFA functionality will be affected. Protectimus Protectimus offers its clients a choice between two deployment options: a Cloud MFA Service or a Self-Hosted On-Premises MFA Platform. This flexibility caters to businesses of all sizes, from a small startup to larger companies and enterprises with strict security and compliance needs. Protectimus Cloud Service The cloud version of Protectimus MFA is a fully managed service hosted in secure, geographically distributed data centers. It allows organizations to: Quickly integrate MFA into their infrastructure with minimal setup. Avoid the overhead of maintaining authentication infrastructure. Scale easily as user count or service coverage grows. Access the Protectimus Administration Panel to set up the settings and reports. All user data, OTP generation, policy enforcement, and access control are managed within Protectimus’ secure cloud backend. Integration usually happens through: API and SDKs (Java, PHP, Python). Pre-built plugins that include connectors for LDAP, Windows, RADIUS, ADFS, Azure AD, OWA, Citrix, VPNs, and others. Protectimus Cloud appears to be very user-friendly for companies looking to lower their infrastructure management without sacrificing security. Protectimus On-Premise Platform For enterprises and government agencies that require complete control over their authentication system, Protectimus offers a full-featured on-premise platform. This platform is installed in the customer’s private infrastructure (local data...
read more