Blog Feed
FortiToken Cost Breakdown: What Fortinet MFA Really Costs vs Third-Party Solutions
Adding MFA to FortiGate should be straightforward. FortiGate is already on your network. Fortinet has its own MFA products — FortiToken Mobile and FortiToken 200 hardware — that integrate natively. No third-party tools, no RADIUS proxy, no extra infrastructure. That’s the pitch. The reality, for many organizations, is that native FortiToken licensing scales less predictably than expected — and FortiAuthenticator, Fortinet’s centralized token management appliance, adds a separate infrastructure cost that isn’t always visible at the point of the initial FortiGate purchase. This article breaks down what Fortinet MFA actually costs, how the licensing model works, and what the numbers look like for a 100-user organization choosing between native FortiToken and a third-party RADIUS MFA approach. What the Fortinet Native MFA Stack Looks Like Fortinet’s MFA ecosystem has three components that typically come up in a FortiGate MFA conversation: FortiToken Mobile is a software OTP application for iOS, Android, and Windows devices. It’s OATH-compliant and time-based (TOTP). The key operational detail: FortiToken Mobile licenses are sold as perpetual licenses registered to a specific FortiGate appliance (for licenses issued after August 2025). A license for 100 users is tied to that one FortiGate — not to your organization or your user directory. FortiToken 200 / 200CD is Fortinet’s hardware OTP token — a small keychain device that generates a 6-digit code every 60 seconds. The 200CD variant ships with an encrypted activation CD for seed security. These are also perpetual, per-unit licenses, tied to the appliance they’re activated on. Note: the FortiToken 200B has been discontinued; current hardware token offerings are the FortiToken 210, 310, and 410 series. FortiAuthenticator is a dedicated appliance (physical or virtual) that centralizes FortiToken management across multiple FortiGate units. Without FortiAuthenticator, each FortiGate handles its own token pool independently — licenses registered to FortiGate-A cannot be used by FortiGate-B. FortiToken Mobile Pricing: What 100 Users Actually Costs FortiToken Mobile licenses are available in fixed user-count bundles. Based on publicly available pricing from authorized resellers (list price, USD): BundleUsers coveredList pricePer-user costFTM-ELIC-1010$958~$96/userFTM-ELIC-2525$2,246~$90/userFTM-ELIC-5050$4,178~$84/userFTM-ELIC-100100$7,638~$76/userFTM-ELIC-200200$13,787~$69/user Source: AVFirewalls.com (authorized Fortinet reseller), list prices as of 2025. Actual prices vary by reseller and region. For 100 users on a single FortiGate, the list price is $7,638 — a one-time perpetual license. That number looks reasonable until you factor in what it doesn’t include. What it doesn’t include: The license is tied to one specific FortiGate appliance. If you need to manage FortiTokens across multiple FortiGate appliances — for example, at different locations — you either need separate license bundles for each FortiGate or FortiAuthenticator to centralize the token pool. For licenses issued after August 2025, the license also cannot be transferred to a different FortiGate appliance (except in RMA scenarios), so replacing the appliance may require purchasing a new license or migrating to FortiIdentity Cloud. If you need hardware tokens for users without smartphones, that’s a separate purchase — FortiToken 210/310/410 hardware, also perpetual per-unit, priced separately. The FortiAuthenticator Factor For organizations with more than one FortiGate unit, FortiAuthenticator is the standard solution to the per-appliance license problem. It centralizes FortiToken management across multiple firewalls and supports a broader range of authentication methods. FortiAuthenticator is available as either a physical appliance or a virtual appliance (FAC-VM). The base VM license supports 100 users. Pricing for the virtual appliance adds to the...
read moreVPN Attacks in 2026: Fortinet, Ivanti, Cisco — Why Passwords Are Not Enough
The three most widely deployed enterprise VPN platforms of the last decade — Fortinet FortiGate, Ivanti Connect Secure, and Cisco ASA — have together produced dozens of critical, actively exploited vulnerabilities between 2022 and 2026. Every major incident response firm has documented the campaigns. CISA has issued emergency directives. Patches have been released. And attackers are still getting in. Not always through new zero-days. Often through credentials. Valid usernames and passwords, obtained from phishing campaigns, leaked configuration files, or breach databases, used against VPN endpoints that accept them without a second factor. The vulnerability patches matter. But they don’t solve the credential problem — and the credential problem is where most of the actual intrusions happen. A Brief Timeline of Major VPN Incidents: Fortinet, Ivanti, and Cisco The scale of VPN exploitation in 2022–2026 is difficult to convey without walking through the actual incidents. Here’s the condensed version. Fortinet — the persistent target Fortinet’s SSL VPN has been a continuous target since CVE-2018-13379 leaked plaintext credentials for approximately 50,000 devices. That vulnerability is still in the CISA KEV catalog. What followed was a chain: CVE-2022-42475 (heap buffer overflow, remote code execution via SSL VPN daemon), CVE-2023-27997 (“XORtigate” — pre-authentication heap overflow, CVSS 9.8), and CVE-2024-21762 (out-of-bounds write in SSL VPN, added to CISA KEV within days of disclosure). The April 2025 Fortinet advisory described the downstream consequence of this chain: attackers had created a symbolic link between the SSL VPN user filesystem and the device’s root filesystem, maintaining read-only access to device configurations — including credentials — even after the vulnerabilities were patched. Organizations that patched promptly could still be affected if the device had been compromised before the vulnerability was remediated. As of July 2026, CISA’s KEV catalog contains 26 confirmed Fortinet vulnerabilities exploited in the wild. In early 2026, Amazon Threat Intelligence documented a separate campaign: a financially motivated threat actor using commercial AI tools compromised over 600 FortiGate devices across 55 countries. The initial access relied on credential attacks against exposed management interfaces rather than a new zero-day vulnerability. Ivanti — the nation-state target Ivanti Connect Secure (formerly Pulse Secure) became a focal point for nation-state actors beginning in December 2023. China-nexus group UNC5221 exploited CVE-2023-46805 (authentication bypass) and CVE-2024-21887 (command injection) in a wave of intrusions that, by January 2024, had compromised over 2,100 devices identified by Volexity’s external scanning — with the actual number likely higher. CISA issued Emergency Directive ED 24-01 requiring federal civilian agencies to take immediate action. Mandiant documented follow-on intrusions deploying custom malware families including ZIPLINE, LIGHTWIRE, and WARPWIRE — a credential harvester specifically designed to extract VPN credentials from device memory. The pattern continued with CVE-2025-0282 (CVSS 9.0, unauthenticated RCE, zero-day exploitation confirmed mid-December 2024) and CVE-2025-22457 (another buffer overflow, mid-March 2025 exploitation, SPAWN ecosystem malware deployed). During these campaigns, UNC5221 also modified Ivanti’s Integrity Checker Tool (ICT) to evade detection, causing compromised devices to appear clean during automated integrity checks. Cisco ASA — the credential spray campaign Cisco’s pattern differs slightly. While Cisco ASA has had serious vulnerabilities (the ArcaneDoor campaign, including CVE-2024-20359 and CVE-2024-20353, demonstrated that sophisticated actors could establish persistent access to Cisco ASA devices), the most documented and widespread attack pattern against Cisco ASA VPN endpoints has been credential-based. Rapid7 and Cisco PSIRT tracked ransomware...
read moreAzure 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 more