What NIS2 Article 21(2)(j) asks for in MFA and secured communications
Article 21(2)(j) asks in-scope entities to use multi-factor or continuous authentication solutions and secured voice, video and text communications, plus secured emergency communication systems within the entity, where appropriate. The provision has two halves. The first concerns how people and systems prove who they are before they reach internal systems. The second concerns whether the channels staff use to talk, meet and send messages during normal operations and during an incident are protected against interception, spoofing and loss. The phrase "where appropriate" means the entity must decide, using its risk assessment, which systems and channels need these controls and document why others do not. A supervisor will ask for that reasoning, not just a list of enabled settings. The risks behind the requirement are credential theft through phishing or password reuse, lateral movement once an attacker holds one valid login, and emergency channels that fail or can be impersonated during the moment they matter most.
The work is hard for predictable reasons. Legacy applications may accept only a username and password, or cannot sit behind a central sign-on service. Shared administrative or service accounts make it unclear who authenticated and when. Many organizations still rely on SMS codes or voice calls for second factors, which are weaker than app-based or hardware-backed options and may not suit privileged access. Before any purchase, confirm with your own inventory which systems lack a central identity provider, which accounts are shared, and which communication channels carry sensitive content. The Implementing Regulation's access control requirements, read in the Commission's implementing regulation text, tie authentication strength to the classification of the asset accessed, so that inventory is the starting point for every later decision.
Which systems, accounts and communication channels fall under this requirement
Article 21(2)(j) reaches every place where a person or system proves identity to reach something that matters, and every channel an entity relies on when it must communicate securely. Scoping starts by listing those access points and classifying the assets behind them, because the classification decides how strong each authentication step must be. The cards below cover the decisions that change the work most.
Internet-facing and administrative access
Any login portal, VPN gateway, web application or API reachable from outside the network is the first scoping decision. Administrative consoles for cloud tenants, hypervisors and network devices carry the same weight because a single compromised session can reach many systems. Inventory each entry point and record whether a second factor or continuous check already applies. Where it does not, the gap goes on the remediation list with an owner.
Privileged and system accounts
The Implementing Regulation requires strong identification and authentication for privileged and system administration accounts, such as multi-factor authentication, and separate credentials for those accounts. Scope every account that can change configuration, grant access or read sensitive data, including break-glass accounts and service identities that a person can log into. Confirm that each one is named, has an owner and is not shared among staff.
Remote and home working access
Remote sessions cross networks the entity does not control, so they usually need the strictest authentication in the estate. Include VPN, virtual desktop, remote support tools and bastion hosts that staff or contractors use from unmanaged devices. Check whether sessions end after inactivity and whether re-authentication happens when the device or location changes. Record which remote paths bypass the central identity provider.
Third-party and vendor access
Suppliers, managed service providers and maintenance engineers often hold accounts that the entity did not create and cannot see in its own directory. List every vendor identity, shared login and support tunnel, then decide whether it moves to named accounts with multi-factor checks and time-limited sessions. Keep the evidence of who held access and when, because supervisors will ask how external access was controlled.
Asset classification sets authentication strength
The Implementing Regulation requires authentication strength to match the classification of the asset being accessed. A payroll system, a production database and a public website should not share one login standard. Agree a classification scheme with the business owners, map each system to a tier, and write down which tiers need multiple factors or continuous authentication. Ask the assessor which classification evidence they expect to see.
Internal communication and emergency channels
Article 21(2)(j) also covers secured voice, video and text communication within the entity, and secured emergency communication systems. Identify the channels that crisis teams, incident responders and management use when normal systems fail, such as conferencing, messaging, out-of-band phone bridges and emergency contact lists. Confirm who can join each channel, how identity is verified and whether the channel stays available during an incident that affects the main identity provider.
How Implementing Regulation 2024/2690 shapes authentication requirements
The Implementing Regulation turns the general wording of Article 21(2)(j) into specific expectations for how users prove who they are. The core rule is that users must be authenticated by multiple factors or continuous authentication where appropriate, and the strength of that authentication must match the classification of the asset being accessed. In practice, this means the classification register for systems and data is an input to authentication design. A reader should be able to point to each sensitive system and state which factors apply to it and why. Confirm with your own assessor how they expect the 'where appropriate' judgment to be documented, because the decision itself must be justified and recorded, not assumed.
Point 11.6.2 of the Annex sets account lifecycle rules that an assessor will test directly. Credentials must be changed at first use, at predefined intervals and whenever compromise is suspected. Users must be blocked after a predefined number of failed log-ins, and inactive sessions must end. Privileged and system administration accounts must use separate credentials from everyday accounts. The thresholds for lockout and session timeout are decisions the organization has to set and write down, so the configuration in the identity provider, such as the policy settings in a platform like authentik or Keycloak, should trace back to an approved standard. Check that administrators cannot bypass these settings by creating personal exceptions.
Point 11.3.2(a) adds that privileged and system administration accounts need strong identification and authentication, with multi-factor authentication given as an example. For most organizations this is the first control to close, since administrator access to identity infrastructure, hypervisors and backup consoles carries the highest impact if abused. A practical check is to list every account with administrative rights across cloud, directory and application layers, then confirm that each one requires a second factor and uses a credential separate from the user's daily login. Records from this review become the evidence an assessor will ask to see.
How an assessor tests MFA and secured communications
This table compares what an assessor samples, what evidence they request and where findings usually appear for each part of Article 21(2)(j). Read it as a pre-assessment checklist: the rows that generate the most findings are the ones where the configuration exists on paper but cannot be shown for every in-scope system.
| Test area | What the assessor samples and reviews | Evidence requested | Common findings |
|---|---|---|---|
| Authentication coverage | Pulls the list of in-scope applications, admin consoles and remote access paths, then checks whether each requires multiple factors or continuous authentication where the asset classification calls for it | Asset inventory tagged by classification, identity provider configuration exports, login flow screenshots or logs for sampled systems | Legacy applications or service consoles that still accept a password alone; classification never applied to assets |
| Privileged account separation | Selects admin and system accounts and checks that they use credentials separate from everyday accounts and carry strong authentication | Account register for privileged roles, group membership exports, evidence that admin logins use a second factor | Shared administrator accounts, daily-use accounts holding admin rights, service accounts with interactive login enabled |
| Lockout and session settings | Reviews the configured failed-login threshold, lockout behavior and session timeout, then tests a sample by reproducing a lockout or observing session expiry | Policy settings, identity platform configuration, test records showing lockout and idle session termination | Thresholds set on one platform but not on connected applications; idle sessions that stay open well beyond the policy |
| Credential rotation | Checks that credentials change on first use, at defined intervals and after suspected compromise, and tests whether the process runs as written | Written rotation rules, forced-change configuration, records of reset events and the incident tickets that triggered them | Default or initial passwords still active; no record of resets after a suspected compromise |
| Recovery and enrollment | Examines how second factors are enrolled, reset and recovered, since recovery paths often bypass the main control | Enrollment and recovery procedures, helpdesk verification steps, sample tickets for factor resets | Recovery by email or SMS alone with no identity check; static recovery codes stored without protection |
| Secured communications | Reviews how voice, video and text channels used for sensitive operations are protected, and whether they run on approved, managed systems | Approved communication tool list, encryption and access settings, usage rules for sensitive content | Consumer messaging apps used for operational decisions; recording or retention settings nobody reviewed |
| Emergency communications | Checks that a secured fallback exists when primary systems fail, and that staff know how to use it | Emergency communication plan, contact lists, records of exercises or activations | Plan exists but depends on the same systems it is meant to back up; no exercise record |
How to implement MFA and secured communications step by step
This sequence turns Article 21(2)(j) into a working setup: every access path is known, authentication strength matches the asset, one identity layer enforces it, and the results are tested and written down in a form a supervisor can inspect. The organization owns each control; an implementation partner or internal team prepares the systems and evidence, and an independent assessor reviews them.
Inventory and classify access paths
List every route into your systems: staff logins, customer portals, remote access, VPNs, administrative consoles, service accounts, APIs and the voice, video, text and emergency channels your staff use to coordinate incidents. For each path, record the application or asset, the users, whether it reaches sensitive or privileged data, and who owns it. Classify each asset by sensitivity so the next step has something to match against. The output is a dated access register signed off by the asset owners. The check: every path in your network diagrams and identity logs appears in the register, and any path without an owner is escalated.
Set authentication strength per asset class
Using the classifications from the register, define the authentication required for each class. Implementing Regulation 2024/2690 expects multiple factors or continuous authentication where appropriate, with strength matched to the classification of the asset accessed. Decide which classes need multi-factor authentication, which can rely on continuous or risk-based checks, and which exceptions need documented justification. The management body or the security owner approves the matrix. The output is an approved authentication standard that names each asset class and its required strength. The check: every class in the register maps to exactly one requirement.
Deploy a central identity layer
Route applications through one identity provider so that users authenticate once, centrally, rather than separately in each application. Open-source options such as Keycloak, authentik and Zitadel can act as the single sign-on or identity broker, and can connect to existing identity providers over standards such as OpenID Connect or SAML 2.0. FreeIPA suits environments that need a directory and Kerberos-based identity management. Your team or the implementation partner configures the provider, connects each application, and confirms which external identity sources are trusted. Confirm each product's current capabilities against its own documentation before choosing. The output is a documented identity architecture with a list of integrated applications. The check: each in-scope application in the register authenticates through the central layer.
Enroll second factors for all users
Require each user to enroll at least one second factor that matches the approved standard. Depending on the platform, this can include time-based one-time password apps, WebAuthn or FIDO2 passkeys, hardware tokens, or, where the standard allows it, SMS or email codes. Plan recovery as part of enrollment: issue recovery codes, define the helpdesk verification process, and decide who can reset a factor. Stronger factors should be required for the higher asset classes. The output is an enrollment record for each user and a documented recovery procedure. The check: a sample of accounts shows an enrolled factor, and no in-scope account can reach a protected asset with a password alone.
Separate privileged and administrative accounts
Create dedicated administrative identities that are separate from everyday user accounts, and require strong identification and authentication for them, such as multi-factor authentication. Limit these accounts to the specific tasks that need them, record who holds them, and review the list on a defined cycle. Service accounts and break-glass accounts need their own documented controls, including owner, purpose and monitoring. The output is a privileged account inventory with owners and approval records. The check: no administrator uses a standard user account for privileged work, and each privileged account has a named owner.
Configure lockout, rotation and session rules
Translate the approved standard into platform settings. Require credential changes at first use, at predefined intervals and on suspected compromise. Block accounts after a predefined number of failed log-ins. End inactive sessions after a defined period. Set these values in the identity provider and in any application that keeps its own login, then record the chosen values and the reasoning behind them. The implementing regulation requires predefined values, so the settings must be written down, not left at vendor defaults without review. The output is a configuration baseline under change control. The check: an exported configuration matches the baseline, and a test account confirms that lockout and session expiry work.
Secure voice, video, text and emergency communications
Article 21(2)(j) also covers secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate. Identify the channels staff use for operations and incident response, including corporate messaging, conferencing, phone systems and any out-of-band channel used when the main network is down. Apply the same identity controls to these tools where they support them, enable encryption in transit, restrict who can join emergency channels, and keep an alternative channel that does not depend on the systems that may be compromised. Confirm each product's encryption and access options with its vendor. The output is a register of communication channels with their protections and an emergency communication procedure. The check: an incident contact test reaches the responsible people through the documented alternative channel.
Test the controls and document the evidence
Test each control against the approved standard. Attempt logins with a disabled factor, a locked account and an expired session. Confirm that privileged accounts cannot be used for standard work and that the emergency channel works. Keep the test scripts, dates, results and the names of the testers, then record exceptions with owners and remediation dates. Feed the results into the Article 21(2)(f) effectiveness review and the management body's oversight. The output is a test report and an evidence pack that links each requirement to its configuration, logs and results. An independent auditor or assessor reviews this evidence and issues any formal opinion. The check: every requirement in the standard has a test result and a retained piece of evidence.
Which self-hosted identity tools fit different environments
authentik is the option to examine when the main gap is that users sign in with a password only and the organization needs a stage that checks a second factor at login. Its authenticator validation stage checks factors a user has already enrolled, which covers time-based one-time password apps, WebAuthn and FIDO2 passkeys, Duo, SMS codes, email codes and static recovery codes. That breadth lets a team choose stronger methods for privileged users and keep weaker ones only where the risk assessment accepts them.
- Factor selection: Decide which methods each asset classification may use, and block weaker methods for administrative accounts.
- Passkeys and FIDO2: Phishing-resistant options suit privileged and administrative accounts, where Annex point 11.3.2(a) of Implementing Regulation 2024/2690 expects strong authentication.
- Recovery codes: Static recovery codes need a documented issuance, storage and retirement process, or they become a bypass.
- Flow design: Authentication stages sit inside flows, so test each application path, including API and legacy entry points, for skipped checks.
- Licensing: authentik is MIT licensed. Confirm the chosen features, support model and any third-party factor integrations (such as Duo) against your own environment.
Before relying on it, confirm that every application you need to protect sends users through the flow that performs the second-factor check.
FreeIPA suits organizations that run Linux and identity infrastructure centrally and need OTP tokens tied to directory accounts. It supports two-factor authentication with HOTP as defined in RFC 4226 and TOTP as defined in RFC 6238, including software tokens enrolled by QR code and hardware tokens such as YubiKeys. It can also proxy OTP checks to an existing RADIUS server during migration, which helps when older network or VPN equipment cannot yet talk to the new directory directly.
- Token enrollment: Define how users enroll software and hardware tokens, and who can reset them after loss.
- RADIUS proxying: Use the proxy as a bridge during migration, and set a retirement date so the old server does not stay in the trust path indefinitely.
- Directory coupling: Account lockout, password policy and group rules are managed in the directory, so changes there affect every service that uses it.
- Hardware tokens: Plan supply, spares and secure disposal for hardware tokens as part of asset management.
- Licensing: FreeIPA is licensed under GPL-3.0-or-later. Confirm the OTP feature set and supported platforms with the vendor and your own operating system policy.
Check whether your applications can consume directory-backed OTP directly, or whether they need a federation layer in front of FreeIPA.
Keycloak fits organizations that want users to authenticate once with a central service instead of separately with each application. Users sign in with Keycloak, which supports OpenID Connect, OAuth 2.0 and SAML 2.0 for the applications behind it. It can also broker logins to existing OpenID Connect or SAML 2.0 identity providers, so a current directory can remain the source of accounts while Keycloak enforces the access policy in front of applications.
- Central enforcement: Attach MFA requirements to the Keycloak realm or client, so applications do not each implement their own checks.
- Protocol coverage: Map each application to OpenID Connect, OAuth 2.0 or SAML 2.0, and record any application that cannot integrate.
- Brokered identity providers: Decide whether MFA is enforced by the upstream provider, by Keycloak, or both, and document the answer.
- Session control: Set session lifetimes and idle timeouts so inactive sessions end as required.
- Licensing: Keycloak is licensed under Apache-2.0. Confirm supported features, clustering and upgrade practice for your deployment.
Verify that every brokered path still triggers the second-factor check you intend, since a trusted upstream login may skip it.
Zitadel suits organizations whose users already sign in through several external providers, such as Google, Microsoft Entra ID or Okta, and who want one broker that applications trust. According to its identity brokering documentation, users can sign in through external identity providers over OpenID Connect, SAML 2.0 or LDAP, so each application trusts one broker instead of every provider separately. That reduces the number of trust relationships to review, but it moves the MFA decision to the point where the broker and the upstream providers meet.
- Trust reduction: Keep an inventory of which providers each application can reach through the broker.
- MFA location: Confirm whether the second factor is enforced by Zitadel, by the upstream provider, or not at all for a given path.
- Protocol mix: Test OpenID Connect, SAML 2.0 and LDAP connections separately, since each has its own attribute and claim handling.
- Audit logging: Ensure login events from every upstream provider reach your central logs for review.
- Licensing: Zitadel is licensed under AGPL-3.0-only. Have counsel confirm that the AGPL obligations fit how you deploy and modify it.
Before choosing this route, confirm the license terms with your legal team and check which upstream providers already enforce MFA for your users.
Evidence that satisfies the authentication requirement
Article 21(2)(j) and the authentication provisions of Implementing Regulation (EU) 2024/2690 are tested through records, not declarations. The six artifacts below show an authority what your authentication rules are, how they are enforced in your identity systems, and whether they still hold between reviews. Each one needs a named owner and a refresh routine, or it will be stale when a supervisor asks for it.
Authentication policy and asset mapping
This is the document that links each asset classification level to the authentication strength required to reach it. Implementing Regulation 2024/2690 expects multi-factor or continuous authentication where appropriate, with strength matched to the classification of the asset accessed. Check that every system in your asset inventory maps to a level, and that the policy names who approves exceptions. Review it when new classifications appear and at least once a year, and record the review date and approver. A policy without an asset-by-asset mapping is hard to defend.
Identity provider configuration exports
Export the realm, flow, and stage configuration from your identity provider and store it under version control. These exports show which second factors are enabled, which login flows require them, and which external identity providers are trusted for brokered logins. Keycloak, authentik, and Zitadel all hold this configuration in ways you can export, so confirm the export format for your product. Re-export after each change and keep the diff, since the change history is often the evidence a reviewer wants.
Enrollment and MFA coverage reports
Coverage reports show what share of accounts have an enrolled second factor and which accounts are exempt. Generate them from the directory or identity store on a fixed schedule, and list every exemption with its reason and approver. Pay particular attention to service accounts, legacy applications that bypass the identity provider, and users who enrolled only SMS codes, which many assessors treat as weaker than app-based or hardware factors. Reconcile the report against the directory so that no account is missing from it.
Privileged account inventory and separation records
Implementing Regulation 2024/2690 requires strong authentication for privileged and system administration accounts and separate credentials for those accounts. Maintain an inventory of every administrative identity, the systems it reaches, and the separate credential used for administrative work. Record each review of standing privileges and each removal. Check that the inventory matches what the directory and the hypervisor, cloud, and database consoles actually grant, because drift between the two is a common finding.
Lockout, credential change and session settings
Export the settings that enforce failed-login blocking, forced credential changes at first use, at set intervals and after suspected compromise, and inactive session timeouts. The implementing regulation sets these requirements in its access control section. Keep the exported values with the date they took effect, and capture a test run showing that a locked account stays locked and an idle session ends. Settings that exist only in a console screenshot are weaker evidence than an export plus a test record.
Communications and emergency channel configuration
Article 21(2)(j) also covers secured voice, video, and text communications and secured emergency communication systems within the entity. Document which channels staff use for incident and crisis coordination, how each is encrypted and authenticated, and what fallback exists if the primary channel fails. Test the emergency channel on a schedule and keep the test records. Confirm the configuration with your communications vendor, since the features that protect these channels differ by product and by plan.
What meeting this requirement costs in money and effort
This table breaks down the cost components of meeting Article 21(2)(j) and shows who is paid for each, whether it is one-time or recurring, and what drives it up or down. No price or duration is stated because none is supplied, so use the right-hand column to decide what to request in a written quote. The main takeaway is that the platform licence is often the smaller share of total effort compared with integration, enrollment and ongoing evidence upkeep.
| Cost component | One-time or recurring | What drives it and what to request in a quote |
|---|---|---|
| Identity platform (self-hosted open source) | Licence cost is usually none for the software itself; hosting and operations recur | Hosting capacity, high availability and backup scope. Ask the implementer to list every component, its hosting model and its patching cadence. |
| Integration engineering | One-time, with later change work | Number of applications moved behind single sign-on, protocol mix (OpenID Connect, OAuth 2.0, SAML 2.0, LDAP) and legacy apps that need adapters. Request a per-application breakdown. |
| Second-factor configuration | One-time build, recurring tuning | Choice of factors (TOTP, WebAuthn or FIDO2 passkeys, email, SMS, recovery codes) and rules that match authentication strength to asset classification. Ask which factors are enabled by default and why. |
| Hardware keys and tokens | One-time purchase, with replacement cycles | Quantity for privileged and administrative accounts, spares and lost-key procedures. Ask who buys, who stores and who issues replacements. |
| User enrollment and support | Recurring, peaks at rollout | Headcount, locations, help desk volume and self-service recovery. Ask for a rollout plan with help desk coverage during enrollment waves. |
| Secured communications (voice, video, text, emergency) | Mostly one-time design, recurring licences from the entity's own telecom or collaboration vendors | Scope of channels the entity runs itself versus those bought from providers. Confirm with each vendor which encryption and emergency features they supply before quoting. |
| Evidence upkeep | Recurring | Exports of enrollment status, failed log-in lockout records, session timeout settings and credential change logs. Ask how often these are produced and who reviews them. |
| External testing of authentication | Periodic, scope-driven | Coverage of login flows, token handling, session management and privileged access paths. Ask for the test scope in writing, including retest rules. |
| Assessor review | Set by the independent assessor | Sample sizes and depth of evidence requested. DeployOpen prepares systems and evidence but does not issue reports; ask the assessor for its fee basis directly. |
Questions buyers ask about MFA under NIS2
Does NIS2 require multi-factor authentication for every account?
No. Article 21(2)(j) asks for multi-factor or continuous authentication solutions where appropriate, so the requirement is proportionate to risk. The Implementing Regulation (EU) 2024/2690 goes further in specific places: users must be authenticated by multiple factors or continuous authentication where appropriate, with authentication strength matched to the classification of the asset accessed, and privileged and system administration accounts need strong identification such as multi-factor authentication. In practice, supervisors will expect you to justify why any high-value or administrative access path lacks a second factor. Document your classification of assets and the reasoning behind each decision.
How does the cost of MFA scale with the size of the organization?
Cost is driven mainly by the number of applications and user populations you bring behind a central identity service, the number of hardware tokens you buy, and how many legacy systems need integration work. Software-based one-time passwords and passkeys carry low license costs with open-source platforms, while hardware keys, help desk procedures for lost devices and migration of existing directories add cost. Ask any provider for a quote that separates one-time items (design, integration, hardened configuration, documentation, testing) from recurring items (support, upgrades, token replacement, staff time for enrollment and recovery).
How long does an MFA rollout take under NIS2?
The duration depends on scope: how many applications, directories and user groups are involved, how much legacy integration is needed, and how much staff training and change management your organization requires. No fixed figure applies to every organization, so ask for a timeline that is tied to a written scope with named deliverables. A phased plan that starts with administrative and remote access accounts is common, because those carry the highest risk and are the accounts the Implementing Regulation singles out.
Can our in-house team implement MFA and secured communications ourselves?
Often yes, if your team already runs identity infrastructure and can test failure paths. Open-source identity platforms such as authentik, FreeIPA and Keycloak support second factors, and skills in directory services, certificate management and protocol integration are the main prerequisites. Teams that lack this experience usually benefit from an outside implementation partner for design, hardening and documentation, while keeping ownership of policy decisions and day-to-day operations. Whichever route you choose, confirm the specific capabilities you need in the product documentation before you commit to a design.
What does MFA under NIS2 require from management and IT?
Management must approve the authentication policy and the risk-based decisions behind it, because the management body is accountable for the Article 21 measures. IT must define asset classifications, set credential change rules, failed log-in lockouts and session timeouts, separate privileged credentials, and plan recovery for lost tokens. Secured voice, video, text and emergency communications also need owners who can name the channels in use and confirm how they are protected. Keep records of these decisions, since they become the evidence a supervisor will ask to see.
Is there a NIS2 certificate for MFA or secured communications?
No. NIS2 creates no certificate of compliance. National competent authorities oversee compliance through inspections, security audits, security scans, information requests and administrative fines. An implementation partner can prepare the systems, configurations and evidence, but only an independent auditor or assessor issues reports, and no such report is a NIS2 certificate. Ask your supervisor or sector regulator which evidence they expect, and use the ENISA technical implementation guidance as a reference for examples of evidence.
Which open-source tools can produce MFA evidence?
authentik validates enrolled second factors at login, including TOTP apps, WebAuthn and FIDO2 passkeys, and recovery codes. FreeIPA supports HOTP and TOTP tokens, including hardware tokens such as YubiKeys. Keycloak provides single sign-on so users authenticate once against a central service, and Zitadel can broker logins to external identity providers. Each tool produces different evidence, such as enrollment records, policy configuration exports and authentication logs, so confirm the exact capabilities against each product's documentation before selecting one.
What to keep in-house and what to outsource
Article 21(2)(j) makes the organization answerable for its authentication and communications controls, whatever help it buys. The cards below separate the decisions that stay with management from the configuration work an implementation partner can carry out, and the independent testing that an auditor or assessor performs.
Authentication policy and risk acceptance
Decide which assets need multiple factors or continuous authentication, how strong each factor must be for each asset classification, and which residual risks management accepts. The Implementing Regulation ties authentication strength to asset classification, so the classification decision comes first. Keep this decision in-house. Check that the signed policy names an accountable owner and that the management body has approved it.
Identity platform configuration and integration
An implementation partner can deploy a self-hosted identity platform inside your infrastructure, enroll second factors, connect applications through single sign-on and set session, lockout and credential-change rules. Ask for written configuration baselines, a list of integrated applications and a named list of privileged accounts that will use separate credentials. The work is fixed in scope, and your team keeps administrative access to the platform.
Privileged account and recovery design
Recovery codes, backup factors and emergency access for administrators are where MFA programs most often fail. Design these with your own security staff, because they decide who can regain access during an outage or a suspected compromise. A partner can build the procedure, but your team should approve it and test it. Confirm that recovery paths are not weaker than the primary login.
Secured communications and emergency channels
Secured voice, video, text and emergency communications depend on operational choices such as which tools staff use during a crisis, who holds the emergency contact list and how fallback channels are kept separate from the systems they support. Your organization decides these requirements. A partner can deploy and document chosen tools. Confirm that a tested out-of-band channel exists for incident coordination.
Evidence preparation
A partner can collect configuration exports, enrollment records, access review extracts and failed log-in lockout logs, and arrange them against the Implementing Regulation's authentication requirements. This preparation makes assessment faster but does not change the findings. Keep evidence in a location your team controls, with a named owner for each artifact.
Independent testing and certification decisions
Only an independent auditor, assessor or certification body can test the controls and issue a report or certificate. NIS2 creates no certificate of compliance, and national competent authorities oversee compliance through inspections, audits and scans. Your partner can prepare systems and evidence, but it cannot attest to them. Ask any assessor how they will test MFA coverage across privileged and standard accounts.
Where MFA programs fall short and how to close the gaps
The most frequent weakness in multi-factor authentication under Article 21(2)(j) is not the absence of a second factor but the accounts and paths that sit beside it. Shared administrative accounts are the first place to look. When several engineers log in with one privileged identity, no second factor can prove who acted, and Implementing Regulation 2024/2690 requires separate credentials for privileged and administrative accounts. Close the gap by issuing named administrative identities, enrolling each with a strong second factor, and keeping any break-glass account sealed, monitored and tested on a set schedule. Confirm with your identity platform how it logs which named account performed each administrative action.
The second common gap is SMS as the only second factor with no recovery plan. SMS is easy to deploy but depends on phone number control, and an account locked out after a lost device can end up reset by help desk staff under weak checks. Keep SMS out of the privileged path where stronger factors exist, such as TOTP apps, WebAuthn or FIDO2 passkeys, which authentik can validate at login. Document a recovery procedure that requires identity verification by a second person, issues time-limited recovery codes, and records every reset as an auditable event.
Legacy applications that bypass single sign-on are the third gap, and they are often the ones holding the most sensitive data. An application that still accepts local passwords sits outside the MFA policy entirely. Inventory every application, route those that support OpenID Connect or SAML 2.0 through Keycloak or Zitadel, and for those that cannot be federated, restrict network access and require a gateway that enforces the second factor. Emergency communication paths, such as out-of-band bridges or fallback phone lines, also need a named owner, a tested activation procedure and a log. Finally, the absence of periodic review evidence is what assessors notice most. Schedule quarterly reviews of enrolled factors, privileged accounts and bypass exceptions, and keep dated records of what was found and fixed.
How DeployOpen scopes and prepares MFA evidence
This sequence turns Article 21(2)(j) authentication duties into a written scope, configured identity controls and an evidence pack that the organization's own independent assessor can test. DeployOpen prepares the systems and evidence, while the organization owns its controls and the assessor issues any report.
Confirm the in-scope entity and applicable obligations
The organization states which NIS2 entity it is, which Member State authority supervises it, and which systems, user populations and communication channels fall under Article 21(2)(j). DeployOpen reviews this with the organization's compliance lead and records the boundary in the draft scope. Done when the organization has signed off the list of applications, identity sources, privileged accounts and communication services in scope. Confirm with the competent authority or legal counsel where the entity classification is unclear.
Inventory identity sources and access paths
DeployOpen maps where users are created, where credentials are stored, which applications authenticate directly and which rely on a central identity provider. The map also records privileged and system administration accounts, remote access routes and any legacy directories still in use. The output is an identity inventory that shows every login path an assessor will ask about. Done when each application and administrative path has a named identity source and an owner.
Classify assets to set authentication strength
The organization classifies the assets accessed through each login path, because the Implementing Regulation expects authentication strength to match asset classification. DeployOpen helps translate those classes into a matrix of which assets require multi-factor authentication, which allow continuous or step-up checks, and which need separate credentials for privileged use. Done when the matrix is approved by the asset owners and the management body's delegated approver.
Select and deploy the self-hosted identity tools
Based on the inventory, DeployOpen recommends and deploys self-hosted open-source components such as authentik for second-factor validation, FreeIPA for OTP tokens in a directory, Keycloak for single sign-on, or Zitadel for brokering external identity providers, where they fit the environment. The deployment runs inside the client's own cloud accounts, data centers or air-gapped network. Done when the chosen components are running in the agreed environment and their versions and configuration are recorded in the change log.
Configure policies for credentials and sessions
DeployOpen configures the authentication policies the organization approved: enrollment of second factors, forced credential changes at first use and at defined intervals, account lockout after a set number of failed log-ins, inactive session termination, and separate credentials for administrative accounts. Where a value such as an interval or lockout threshold is needed, the organization sets it in its own policy rather than taking a default. Done when each policy is exported as configuration and tested against a sample user in a non-production tenant.
Test secured communication and emergency paths
For voice, video, text and emergency communication channels in scope, DeployOpen checks how access is authenticated and how the channel is protected, and records gaps the organization must close or accept in writing. Where a channel sits outside the identity platform, the organization decides its controls with its vendor. Done when each channel has a test record showing who can use it, how they authenticate, and what happens during an outage.
Assemble the evidence pack for the independent assessor
DeployOpen compiles configuration exports, the identity inventory, asset classification matrix, test results, access review records and change logs into an evidence pack organized by control. The pack is handed to the organization, which decides what the independent auditor or assessor receives. DeployOpen does not issue audit reports, attestations or certifications; only an independent assessor or certification body does. The work is priced from a written scope, and the quote follows from that scope before any work starts.
