NIS2 itself says only that an organisation must use “multi-factor authentication or continuous authentication solutions … where appropriate” (Article 21(2)(j), Directive 2022/2555). The three Baltic states turned that one line into three quite different sets of rules. If you run systems in more than one of them, or you are trying to work out which of your accounts a regulator will ask about, the differences matter. This post quotes the clauses and says where each one leaves room.
The EU-level exception first: providers of digital infrastructure such as DNS, cloud, data centres, managed service providers and online marketplaces follow the Commission’s implementing regulation instead of national rules. Its Annex point 11.7 requires MFA or continuous authentication for access to network and information systems “in accordance with the classification of the asset”, and point 11.3.2 requires strong authentication “such as multi-factor authentication” for privileged and system-administration accounts (Regulation 2024/2690, in force since 7 November 2024). Everyone else follows the national rules below.
Latvia: the regulation names the accounts
Latvia’s rules are the most specific of the three. Cabinet Regulation No. 397, Minimālās kiberdrošības prasības (Minimum cybersecurity requirements), has been in force since 2 July 2025 (likumi.lv) under the National Cybersecurity Law (likumi.lv).
Point 52 makes MFA mandatory for:
- 52.1 administrator accounts and standard user accounts of class A information systems;
- 52.2 administrator accounts of class B information systems;
- 52.3 standard user accounts of class B systems when they are accessed remotely from an external network and that access does not already go through an encrypted VPN with MFA.
The classes are a property of each information system, not of your organisation. Points 32 to 34 derive them from the system’s confidentiality, integrity and availability security classes: one A rating makes it a class A system, otherwise one B rating makes it class B, and anything that is part of critical infrastructure is class A by definition. An essential service provider can have only class B and C systems, and the regulation allows for this: its three-yearly self-assessment cycle covers any entity without a class A system.
Point 55.8 adds a network rule for owners of ICT critical infrastructure and for essential service providers: access from outside the internal network to internal resources “is possible only through an encrypted VPN solution with multi-factor authentication”. Point 56 applies only 55.1 to 55.4 to important service providers, so 55.8 does not bind them.
Around the MFA rule sit obligations that an auditor will check in the same visit: administrator accounts must not be used for day-to-day work and standard accounts must not be used for administration (points 51.5 and 51.4); access to information resources, including failed attempts, must be logged (point 58.3) and kept for 18, 12 or 6 months depending on the system class (point 57). A self-assessment report on the regulation’s Annex 16 form is due by 1 October each year for critical-infrastructure owners and anyone with at least one class A system, and every three years for the rest (points 141 and 142); it goes to the National Cybersecurity Centre, or to the Constitution Protection Bureau for critical infrastructure.
What the regulation does not do: it names no technology. “Daudzfaktoru autentifikācija” is all it says, with no mention of SMS, one-time codes, FIDO or phishing resistance, and it sets no password rules at all. Fines under the law reach €10 million for essential providers, or 2 % of turnover if turnover exceeds €500 million, and €7 million for important providers, or 1.4 % of turnover above the same €500 million threshold.
Lithuania: everyone, users included, on a 24-month clock
Lithuania rewrote its Cybersecurity Law for NIS2 with effect from 18 October 2024. Article 14(5)(11) lists “multi-factor or continuous authentication solutions” among the required elements, and Government Resolution No. 945 of 6 November 2024 (in force 12 November 2024) approves the detailed Kibernetinio saugumo reikalavimų aprašas (e-seimas).
The MFA rule is in Table 7 of that description, row 61, and it is the broadest of the three countries: “the user and the administrator must confirm their identity with a password and an additional authentication means (multi-factor authentication)”. It is ticked for essential and important entities alike, and it does not depend on where the user is or how the system is classified. Around it: administration only through a separate account not used for daily work (row 58), accounts suspended after three months of inactivity for users and two for administrators, workstation lock within 15 minutes, and browsers not allowed to save passwords outside a dedicated password manager. Third parties get MFA “where possible”. The organisational part, including a written access-management procedure that states how MFA is used (point 65.9), is due 12 months after registration in the national cybersecurity information system; the technical requirements in Table 7, MFA included, are due 24 months after registration (point 72).
The law also requires a cybersecurity audit at least every three years under the centre’s methodology, and management training at least every two. Obligations start only once an entity is registered (Article 11(2)), the National Cyber Security Centre supervises. A breach of the Article 14 requirements counts as a “dangerous violation”, the top fine tier: up to €10 million or 2 % of worldwide turnover, whichever is higher, for essential entities, and €7 million or 1.4 %, whichever is higher, for important ones. Budget institutions have lower caps. The law was amended again in June 2026; we have not been able to read that text, so check whether the articles on fines and on registration changed.
Estonia: the law is silent, the standard is not
Estonia’s amended Cybersecurity Act (Küberturvalisuse seadus) took effect on 1 January 2026 (Riigi Teataja). It calls essential entities üliolulised üksused and important ones olulised üksused, and it does not mention multi-factor authentication anywhere. Instead, section 7 delegates the security measures to a Government regulation, and that regulation gives providers a choice: implement the Estonian information security standard E-ITS, or demonstrate that their measures meet ISO/IEC 27001, with a compliance audit every three years (Regulation 121).
MFA then shows up twice. The regulation’s annex of primary measures, which applies to every provider under the Act, tells them to “prefer multi-step authentication” (point 2.5), a soft wording that providers may replace with an equivalent measure. The E-ITS baseline catalogue is firmer: where the system allows it, MFA is used instead of password-only authentication (ORP.4.M8); privileged accounts are protected with MFA against external attackers and privilege escalation (ORP.4.M10); for high protection needs, secure MFA “for example with an ID card or a token” (ORP.4.M21); and MFA for access to sensitive personal data (CON.2.M18) (E-ITS catalogue).
The deadlines are generous. Entities that already qualified on 1 January 2026 had to register with the Information System Authority (RIA) within three months, so by the end of March 2026, and have three years, until the start of 2029, to bring themselves into full compliance. New entities have three months to register and three years from qualifying. Fines mirror NIS2: up to €10 million or 2 % of worldwide turnover for essential entities and €7 million or 1.4 % for important ones, whichever is higher in each case. RIA supervises important entities only after the fact.
Side by side
| Latvia | Lithuania | Estonia | |
|---|---|---|---|
| Instrument | Cabinet Regulation No. 397, in force 2 Jul 2025 | Law of 18 Oct 2024 + Resolution 945, in force 12 Nov 2024 | Act amended 1 Jan 2026 + Regulation 121 + E-ITS |
| MFA required for | All accounts on class A systems; admins on class B; remote users on class B without MFA-VPN | Every user and administrator, essential and important alike | Annex: “prefer” multi-step authentication, for all; E-ITS: MFA where the system allows it and for privileged accounts |
| Remote-access rule | VPN with MFA for critical infrastructure and essential providers (55.8) | None specific | None specific |
| Technology named | No | No | E-ITS gives ID card or token as examples for high protection |
| When | Now | 24 months after registration for technical measures | 3 years from qualifying (2029 for existing entities) |
| Evidence | Self-assessment by 1 Oct, yearly or every 3 years | Audit at least every 3 years | E-ITS or ISO 27001 audit every 3 years |
| Supervisor | National Cybersecurity Centre; Constitution Protection Bureau for critical infrastructure | National Cyber Security Centre | Information System Authority (RIA) |
What this means for the accounts you actually have
- VPN and remote access. In Latvia, an encrypted RADIUS VPN with a second factor is what 55.8 asks of critical-infrastructure owners and essential providers, and it takes class B users out of 52.3; without it, every remote class B user needs MFA on the application itself. In Lithuania the VPN does not change the rule, because every user needs MFA anyway. In Estonia the E-ITS line “where the system allows it” is the question to expect about a VPN that supports RADIUS.
- Administrators. Administrator accounts are where the three rules overlap most: Latvia requires MFA for them on class A and B systems, Lithuania everywhere, E-ITS on all privileged accounts. Latvia and Lithuania also both require a separate admin account not used for daily work. Firewall and server consoles that still take a password alone are the most likely finding.
- Evidence. Latvia wants failed logins logged and kept; Lithuania wants a written procedure that says how MFA is used; Estonia wants an audit against a standard. An authentication method that produces a signed, timestamped record of each approval gives you material for all three without reconstructing it after the fact.
- Technology. No Baltic law prescribes a method, and none uses the words “phishing-resistant”. ENISA’s implementation guidance recommends phishing-resistant MFA “wherever possible” and lists FIDO2 at the top; the national texts stop at “multi-factor”. That is a floor, not a target, and the NIS2 authentication post explains what separates a factor that satisfies the words from one that survives an attacker.
Notakey adds a phone approval, shown with the service, the account and the source address, to RADIUS VPNs, firewall and server logins, Windows and web applications, and leaves a signed record of every approval on an appliance you can run in your own data centre. The VPN 2FA guide shows how it fits a class B remote-access requirement in Latvia or row 61 of Table 7 in Lithuania. Request a demo and we will map the accounts your national rule names to a pilot, or try the live demo on your own phone first.
This article quotes the legal texts as published on 29 October 2026 and is general information, not legal advice. Confirm the obligations, classes and deadlines that apply to your organisation with qualified counsel, and check the Lithuanian amendments of June 2026, which we could not read when writing.