How authentik supports NIS2 MFA and access control requirements
An essential or important entity under NIS2 must show that MFA and access control are in place under Article 21(2)(j) and Article 21(2)(i), and that the detailed technical expectations of Implementing Regulation 2024/2690 are met for the systems in scope. authentik helps with the technical controls: enforcing MFA by group and by application through its flow and policy configuration, separating privileged administrator identities from everyday accounts, running identity lifecycle actions such as deactivation, and producing authentication and admin event logs that you can keep as evidence. It does not write your access control policy, run your HR onboarding and termination process, maintain your asset register, or replace the planned reviews of access rights that the regulation expects. Those remain organizational work that authentik can feed but not perform.
Before you design the rollout, map each application in scope to the classification of the asset it accesses, because Implementing Regulation 2024/2690 (points 11.7.1 and 11.7.2) expects authentication strength to match that classification. Confirm in your own environment which authentik event types and retention settings you will rely on for failed log-in handling and privileged sign-ins, and check how those logs will reach your monitoring. Confirm the current authentik security policy and supported release line before you commit to a version, since the project lists which versions receive security fixes. The Implementing Regulation text is available on EUR-Lex and should be the reference for your mapping.
NIS2 issues no certificate of compliance. National competent authorities supervise through inspections, security audits, scans, information requests and administrative fines, so the question an authority will ask is whether you can show working controls and records. DeployOpen prepares configurations, runbooks and evidence for that review, but it does not issue audit reports, attestations or certifications, and an independent assessor is needed for any formal assurance you choose to obtain. Ask for the written scope, the evidence list and the test steps before work starts, so that what you receive can be checked against your national transposition law and the regulator's expectations in your Member State.
Mapping NIS2 and Implementing Regulation 2024/2690 requirements to authentik configuration
This table maps each NIS2 and Implementing Regulation 2024/2690 authentication and access requirement to the authentik capability that supports it, the settings to verify in your installed version, and the duties that stay with your organization. Read each row as a starting point for your evidence file, and confirm menu names and stage behavior against the release you run.
| Requirement | authentik capability | Configuration to confirm | What remains with the entity |
|---|---|---|---|
| Article 21(2)(j): MFA or continuous authentication where appropriate | Authentication flows can include an MFA stage, bound to applications through policies and groups across OIDC, SAML, proxy and LDAP providers. | Which applications and groups require MFA; which factors are enabled; whether LDAP and RADIUS clients enforce a second factor (confirm per provider). | Deciding where MFA is appropriate, documenting that decision, and covering access paths outside authentik. |
| Annex 11.7.1 and 11.7.2: authentication strength matched to asset classification | Different applications can be bound to different flows, so stronger authentication can follow a higher classification. | A register linking each classified asset to its application and flow binding; test each binding with a non-admin account. | Classifying assets, setting the strength each class requires, and reviewing the mapping when classes change. |
| Annex 11.6.2: credential changes initially, periodically and on suspected compromise | Password policies and stages can force a change at first login; forced resets can be run for specific users or groups. | Forced change at first login; the interval your version supports; the procedure for a forced reset after suspected compromise. | Setting the interval, defining what counts as suspected compromise, and running the reset procedure. |
| Annex 11.6.2: block users after a predefined number of failed log-ins | Failed-attempt handling can be enforced through policies on the authentication flow (confirm the mechanism in your version). | Threshold value, lockout duration or unlock method, and whether lockouts appear in the event log. | Choosing the threshold, the unlock authority, and how locked-out users are verified before reset. |
| Annex 11.6.2: end inactive sessions | Session lifetime and inactivity behavior are set on the flow, provider or session settings (confirm exact fields in your version). | Session and token lifetimes per provider; inactivity timeout for administrative and high-classification applications. | Choosing timeout values per asset class and confirming that relying applications also enforce them. |
| Annex 11.3.2(a) and 11.6.2: separate, strongly authenticated privileged credentials | Administrative access can be restricted to a dedicated group with a flow that requires MFA, separate from day-to-day user accounts. | Admin group membership; no shared admin accounts; MFA on the admin flow; a documented break-glass account with its own controls. | Approving privileged roles, storing break-glass credentials securely, and separating administrator duties. |
| Annex 11.2.2 and 11.2.3: need-to-know, least privilege, register and periodic review | Group membership and application bindings define who reaches which application. Membership can be exported for review. | Scheduled exports of group membership and bindings; a named owner for each application group. | Maintaining the access register, approving requests, setting review intervals and recording review outcomes. |
| Annex 11.5.2 to 11.5.4: identity lifecycle, one person per identity, shared identities and prompt deactivation | User accounts can be deactivated. SCIM provider types can provision and deprovision accounts from an upstream source. | Deactivation steps in the joiner, mover and leaver process; flags and approvals for shared identities; SCIM settings if an HR source drives changes. | Defining HR triggers, timing of terminations, approving shared identities, and keeping approval records. |
Enforcing MFA by group and application in authentik
The entity, not authentik, decides which applications need a second factor and how strong that factor must be. authentik can enforce MFA at the level of an application or a user group through its flows and policies, so the work starts with a written classification scheme. Define the tiers (for example, a tier for systems holding critical operational data and a tier for general internal tools), assign each application to a tier, and map each tier to the user groups allowed to reach it. Article 21(2)(j) asks for multi-factor or continuous authentication where appropriate, and Implementing Regulation 2024/2690 expects authentication strength to match the classification of the asset accessed. Without that register, no policy binding can be justified to an assessor.
In authentik, the translation into configuration is a set of policy bindings: the application or provider is bound to an authentication flow that includes a second-factor stage, and group or policy conditions determine who is challenged and when. Plan the group structure before building bindings, so that membership reflects the role-based register required by Article 21(2)(i) and Annex point 11.2.3. Treat the tier-to-factor mapping as a decision record with an owner, not as a default setting that an administrator can change silently.
Before relying on any tier design, confirm which second factors and policy bindings your chosen authentik version supports for each application type. Support differs between providers, and some protocols such as LDAP or RADIUS need separate handling. Check the MFA and flows documentation topics in this pillar for the current factor list and binding options, then test each tier with a non-administrative account and an administrative account. Record the test results alongside the classification register, since they form part of the evidence an auditor or supervisory authority will ask to see.
What evidence authentik leaves for NIS2 assessors
An assessor will look for proof that MFA, access rights and identity lifecycle actually operated, not only that they were configured. The records below come from authentik's configuration, its event logs and your own procedures, and they only carry weight when they are read together.
Configuration exports and blueprints
Export the authentication flows, MFA stage bindings, group memberships and application policy bindings on a schedule, or manage them as version-controlled blueprints. Each change then has a commit author, a date and a reason, which shows what the MFA-by-group and by-application rules were at any point in time. Check that the export captures stage bindings and policies, not just the object names, because a missing binding is the gap an assessor finds first. Store exports outside the running instance so they survive a compromise of it.
Authentication and admin event logs
authentik records login, MFA challenge, authorization and administrative actions in its event log. Forward these events to a central log platform so they cannot be edited by the people whose activity they record. Confirm that privileged account sign-ins and changes to MFA stages, flows and policies are captured, and test that a sample admin action appears with the acting user's identity. Enhanced audit logging is listed as an Enterprise feature, so confirm whether your edition meets the depth you need.
Access register exports
Article 21(2)(i) expects access rights to be recorded in a register and reviewed at planned intervals. Export group membership and application bindings from authentik at each review, then compare them with the approved register and the HR records behind it. Each review should show who approved each grant, who changed it and when it was last confirmed. Keep these exports with the review sign-off so the register and the system state can be shown to match.
Deactivation records from the lifecycle process
Termination and role change are where access most often outlives its need. Keep a ticket or HR event for each leaver and mover, the time the account was deactivated in authentik, and the removal of group memberships and application bindings. Gaps between the HR event and the deactivation timestamp are what assessors measure. Also record any shared identity that was approved explicitly, since shared accounts need a documented owner and approval.
Failed login and lockout records
The lockout policy after a set number of failed log-ins should produce a visible record, both in the event log and in the account state. Retain these entries alongside the threshold configuration that was in force at the time, because the threshold changes what the events mean. Review them periodically and document the outcome, including investigations of repeated failures against privileged accounts. Confirm how your chosen policy records a lockout and whether it can be queried after the fact.
Written procedures that tie records together
No single export proves compliance. The written procedures for MFA enrollment, credential changes, access reviews, leaver handling and lockout response explain why each record exists and who acts on it. Map each procedure to the records it produces and to the Annex points it supports, and version it with the configuration. Competent authorities and auditors decide whether this evidence is sufficient for your entity, so confirm the expected format and retention period with them before you rely on it.
How identity lifecycle and privileged accounts are handled
How do I link each identity in authentik to a single person?
Each authentik user account should map to exactly one named individual, and the entity must own that rule through its joiner process rather than relying on authentik to enforce it. Confirm in your authentik version how user records are created (manually, through enrollment flows, or through a source or SCIM feed) and restrict who can create accounts. Keep a register that ties each username to an employee or contractor record in your HR system, and review duplicates during access reviews. The process owner is usually HR together with the identity team, and the register is the evidence Implementing Regulation 2024/2690 expects you to keep.
When do shared identities in authentik need approval?
Shared identities should be the exception, and each one needs explicit approval from a named owner before it exists. Confirm how your authentik instance records the account owner, the business reason and the approval, for example through a ticket reference stored in the user attributes or an external change record. Limit shared accounts to the systems that truly require them, prevent them from holding privileged roles where possible, and assign a named accountable person who can answer for their use. Review the list of shared identities on a planned schedule and remove any that no longer have a justification.
How quickly should unneeded identities be deactivated in authentik?
Deactivate unneeded identities without delay, which means the trigger for removal must be built into the leaver process, not left to a periodic clean-up. In authentik, confirm whether you deactivate the user (blocking login) rather than deleting it, so audit history remains available. Make sure deactivation also removes group memberships that grant application access, and check that every connected application honors the change, including sessions issued by proxy outposts or LDAP clients. Your HR termination steps should name who triggers the change and how fast it must happen, and you should test the path with a sample leaver.
How are separate admin accounts created and held in authentik?
Privileged and administrative work should use separate accounts that are distinct from each person's everyday login, and those accounts need multi-factor authentication. In authentik, confirm how administrator roles are granted (through group membership and the built-in admin roles) and create dedicated admin users that are not used for email or routine browsing. Keep the admin group small, require MFA enrollment for it, and grant rights only for the duration of the task where your process allows. Hold the list of admin accounts in your access register, review it on a planned interval, and remove rights on role change.
How do I configure session ending for authentik users?
Session ending is a configuration decision that you must confirm in your authentik version, because session lifetime and inactivity settings are controlled through flows, policies and the session settings your instance exposes. Decide the inactivity limit for standard users and a shorter limit for privileged roles, then document the values in your access control policy. Test that inactive sessions actually end, including sessions opened through forward auth or LDAP and RADIUS clients, which may behave differently. Record the chosen values and the test results as evidence.
How do I require periodic and compromise-driven credential changes in authentik?
Implementing Regulation 2024/2690 requires credential changes at first use, at predefined intervals and when compromise is suspected, so your entity must set those intervals and own the triggers. In authentik, confirm which password and authenticator policies, flows or stage settings support forced change at first login and at a set interval for your version, and whether MFA reset can be forced. Compromise response is a process: define who can disable an account and reset credentials, and how the event is logged. Keep the policy text, the configured settings and a sample of forced-change events as evidence.
Which parts of the identity lifecycle does my own team need to own?
Your team must own the decisions and records, while authentik enforces the technical steps. Ownership includes the joiner, mover and leaver rules, the approval for shared identities, the admin account register, the review schedule and the termination timeline. Confirm with your implementation partner or internal team which steps authentik automates in your setup, such as group changes from a directory or SCIM feed, and which remain manual. Reviewing these ownership points before go-live prevents gaps that auditors and national authorities look for.
What authentik does not cover for NIS2
authentik answers the identity and authentication parts of NIS2 Article 21(2)(i) and (j). Several other requirements in Implementing Regulation 2024/2690 sit with HR, facilities, asset records, communications tooling and written policy, so they need their own owners and evidence. The cards below cover what remains outside authentik and what to confirm before relying on it.
HR security and background verification
Annex point 10 of Implementing Regulation 2024/2690 covers background verification, disciplinary process and termination procedures. authentik can disable an account quickly, but it does not know who has joined, changed role or left. Connect joiner and leaver events from your HR system or a lifecycle tool, and confirm who records the termination date that triggers deactivation. Ask your HR team to keep the verification records outside the identity platform.
Physical access control
Point 13.3 of the Annex addresses physical access control, which covers doors, badges, visitor logs and server room entry. authentik governs logical access only. A badge system or building access platform will not be replaced by authentik, and a user's logical access does not prove physical presence. Document the physical controls separately and state in your evidence pack which system holds each record.
Asset management and inventory
Annex point 12 requires an asset inventory and classification. authentik knows the applications and providers it protects, but it is not a complete asset register. Authentication strength under point 11.7 depends on classifying each asset, so the classification must come from your inventory. Confirm that every application in authentik maps to a recorded asset with an owner and a classification level.
Secured voice, video and emergency communications
Article 21(2)(j) also asks for secured voice, video and text communications and secured emergency communication systems. Those channels are usually provided by messaging, conferencing and telephony products that need their own identity configuration and encryption settings. Confirm with each product owner whether it can use authentik for sign-in and MFA, and where emergency communication does not depend on the identity provider being available.
Policy and risk management documentation
Article 21 requires risk-management measures, and the regulation expects written access control policies and procedures. authentik can enforce settings, but it cannot write your policy or perform your risk assessment. Prepare the written access policy, the MFA and password policy, and the review cadence, then map each statement to the authentik setting that enforces it.
National transposition and enterprise features
NIS2 is a directive, so national laws can add obligations or set details, and Article 5 allows stricter rules. Confirm your national competent authority's expectations before you finalize the design. Also check that required controls are not behind a paid tier: the authentik pricing page lists privileged access management, enhanced audit logging and password history as Enterprise-only features, so verify each one against the requirement before you assume it is covered.
Configuration sequence for a NIS2 access control baseline
This sequence turns authentik into a documented access control baseline for NIS2 Article 21(2)(i) and (j). Each step ties a configuration change to an Implementing Regulation 2024/2690 requirement and to the record it leaves for your supervisor or auditor.
Classify assets and applications into tiers
Your risk owner and application owners list every application and system that authentik will sign users into, then assign each one to an authentication tier based on the sensitivity and impact of the assets it exposes. The regulation requires authentication strength to match the classification of the asset accessed (points 11.7.1 and 11.7.2 of the Annex), so the tiers must exist before any MFA policy is written. The output is a register with one row per application, its tier, its owner and the date the owner approved it. You know the step is complete when every application in authentik has a tier recorded and no application is left unclassified.
Define groups and need-to-know roles
Create authentik groups that represent job functions, then bind each group to the applications and tiers it needs. Keep administrative rights in separate groups so that no single group grants both application use and platform administration. This supports the need-to-know, least privilege and separation of duties principles in points 11.2.2 and 11.2.3 of the Annex. The output is a group-to-application matrix, exported from your configuration and placed in the access register. You know the step is complete when every access grant traces back to a named group and a documented business need.
Configure MFA policies for each tier
Attach authenticator requirements to flows and applications through policies bound to the groups and tiers from the earlier steps. Standard users in higher tiers should be prompted for a second factor, and privileged roles should use the strongest authenticators your environment supports. Confirm which second-factor types each authentik version offers and how the regulation's multi-factor or continuous authentication expectation applies to your asset classes with your legal and security leads. The output is a policy map and test logins for each group. You know the step is complete when a test account from each group is challenged as the map specifies and a failed challenge is logged.
Create separate privileged accounts
Give each administrator a dedicated administrative identity that is separate from their everyday account, and link it to one named person. Place these identities only in administrative groups, require MFA on them, and do not use them for routine work. Point 11.6.2 of the Annex requires separate credentials for privileged or administrative accounts, and point 11.3.2(a) requires strong authentication for them. The output is a list of privileged accounts, each mapped to a person and an approving manager. You know the step is complete when no administrative group contains an account that also serves as a daily user identity.
Set failed login and session rules
Configure how many failed log-ins trigger a block, how long sessions remain idle before they end, and when users must change credentials. Point 11.6.2 requires blocking after a predefined number of failures, ending inactive sessions, and forcing credential changes at initial use, at predefined intervals and on suspected compromise. The regulation does not supply the numbers, so your risk owner must set and document each value, and you should confirm which lockout and session settings your authentik version provides. The output is a signed authentication standard with the chosen values and screenshots or exports showing them. You know the step is complete when a test account is locked after the documented number of failures and an idle session ends at the documented time.
Connect lifecycle steps to joiners and leavers
Define how a new hire receives an identity, how a role change updates group membership, and how a leaver is deactivated. Each identity must link to a single person, shared identities need explicit approval, and unneeded identities must be deactivated without delay, as set out in points 11.5.2 to 11.5.4 of the Annex. Access changes on termination or role change are required by points 11.2.2 and 11.2.3. Where your HR system will feed authentik, confirm which provisioning method your version supports. The output is a written joiner, mover and leaver procedure and a tested deactivation record. You know the step is complete when a test leaver loses access to every bound application.
Enable log retention and export
Decide where authentik's authentication and administrative events are kept, how long they are retained, and how they are exported to your central logging platform. Retention periods come from your own policy and the obligations you carry under national transposition law, and you should confirm with your vendor which event types and export options your edition includes, since enhanced audit logging is listed as an enterprise feature. The output is a log retention standard and a sample event for each control in this sequence, such as a failed login, an MFA challenge, a privileged sign-in and a deactivation. You know the step is complete when each sample can be retrieved from the central store.
Schedule access reviews
Set a review interval for each tier, assign a reviewer who is not the person who administers the group, and run the first review against the access register. Point 11.2.3 requires access rights to be reviewed at planned intervals, and the interval itself is a decision for your entity and should be recorded with its justification. The review compares group membership and privileged accounts against the register, then records removals and approvals. The output is a signed review record for each cycle, linked to the change tickets that followed. You know the step is complete when each review is dated, signed and traceable to corrective actions.
What does an authentik NIS2 access control project involve?
What drives the cost of an authentik NIS2 access control project?
The main drivers are the number of applications that need MFA, how many asset tiers you need to separate, how many directories and upstream sources must be connected, and whether you need Enterprise features. Each application that uses a different protocol (OIDC, SAML, LDAP, proxy or RADIUS) adds configuration and testing work. Each asset tier adds a policy decision about which authentication strength applies. Enterprise-only items such as mTLS client certificate authentication, privileged access management, password history and enhanced audit logging are priced separately on the authentik pricing page, so confirm which of them your evidence plan depends on before the quote is written. DeployOpen does not publish a price list. Ask for a fixed-scope quote that lists each application, tier, integration and edition assumption in writing.
How long does an authentik NIS2 access control project take?
Duration depends less on the software than on decisions the entity must make first. Before build work starts, you need a classification of which systems are in scope and which authentication strength each asset tier requires, a register of who holds which access rights, and named owners for HR joiner, mover and leaver processes. Approvals for shared identities, privileged credentials and break-glass accounts also take time because they depend on internal governance calendars. No duration is set by the regulation or by authentik, so ask for a timeline in the written scope that shows which dependencies sit with your team and which sit with the implementation partner.
What does the entity need to provide for an authentik access control project?
The entity needs to provide decisions and access, not only infrastructure. Typical inputs include:
- A list of in-scope applications and the people or roles who use them
- Your asset classification and the authentication strength you require for each class
- Named HR process owners who confirm joiner, mover and leaver events and termination steps
- Approvers for shared identities, privileged accounts and exceptions to MFA
- Access to cloud accounts, data centers or air-gapped networks where authentik will run, and to the directories it will read from
Without these inputs, the configuration cannot reflect your actual policy, and the evidence will describe a default rather than your controls.
Can our internal team run an authentik NIS2 access control project alone?
Yes, if your team has the skills and capacity to run the work, and many entities do part of it internally. Your team must be able to deploy and operate authentik on PostgreSQL, configure flows and policies, connect applications over the relevant protocol, manage separate administrator credentials and produce logs for review. The harder parts are often governance: agreeing the classification, writing the access control policy, and tying HR events to identity changes. An external partner can cover fixed-scope parts such as deployment, hardening, integration and documentation, while your staff keep ownership of policy and approvals. Confirm the split in writing so that each NIS2 control has a named owner on your side.
Which parts of an authentik NIS2 access control setup are one-time and which recur?
Most of the build is one-time: deployment, initial policies, application integrations, admin credential separation and the first set of documentation. Recurring work includes access reviews at planned intervals, which NIS2 implementing requirements expect for access rights, credential changes at predefined intervals, removal of identities when people leave or change roles, and handling failed log-in thresholds and inactive sessions in daily operations. Software upkeep is also recurring. authentik publishes security releases with at least 24 hours of advance notice and supports only specific versions for security fixes, so plan upgrades as a standing task. Ask any partner to separate one-time fees from retainers in the quote.
Can authentik or DeployOpen certify NIS2 compliance for us?
No. NIS2 does not create a certificate of compliance. National competent authorities supervise compliance through inspections, audits, scans, information requests and administrative fines. authentik is open-source software, and DeployOpen plans, implements, hardens, documents and supports self-hosted platforms and prepares systems, controls and evidence for assessments. DeployOpen does not issue audit reports, attestations or certifications, and neither does authentik. Your competent authority or the body it designates decides whether your measures meet the requirements. Use the project to produce the configuration, records and evidence your supervisor may ask for, and confirm with your national authority which evidence it expects.
Does an authentik NIS2 project require the Enterprise edition?
Not necessarily. The open-source edition covers the core provider types and flows, and the repository is under the MIT license for most of the code, while the enterprise directory has its own license. Enterprise adds features that some access control designs need, including mTLS client certificate authentication, privileged access management, password history, enhanced audit logging and ticket-based support. Enterprise Plus adds dedicated support with SLAs and FIPS compliance for FedRAMP requirements. Check each NIS2 requirement against the feature list before deciding. If your evidence plan depends on enhanced audit logging or password history, price the edition into the scope from the start, and confirm current terms on the authentik pricing page.
Keeping the control running after go-live
The MFA and access control design only stays compliant if the platform underneath it keeps receiving security fixes. Plan authentik upgrades on the release lines that the authentik security policy lists as supported for security fixes, which are the 2026.5.x and 2026.8.x lines at the time of writing, and confirm that list again before each planning cycle. The project announces security releases at least 24 hours in advance, so the operations owner needs a standing way to receive that notice and a test environment that can take a patch within the same working day. Version names follow year and month, and the latest release shown in the authentik releases page should be checked against your own running version at every review. Upgrades should also be run in a staging copy that uses the same flows, policies and MFA stages as production, so that a change to a stage binding does not silently remove MFA from a group.
PostgreSQL is the single data store for configuration, sessions, caching and background tasks, because authentik no longer uses Redis. Treat the database as the part of the NIS2 control that needs the most capacity planning. The 2025.10 release notes warn of roughly 50% more PostgreSQL connections after upgrading, so confirm connection limits, pooling and backup restore tests before any upgrade that crosses that release. Scheduled access reviews should be recorded in your access register, covering who holds the administrator and MFA-bound groups, which applications each group reaches, and whether privileged accounts still use separate credentials. Re-test MFA enforcement on a fixed schedule by attempting logins from an unenrolled account and from a session that skips the second factor, and keep the results as evidence.
Audit logging and privileged access management are where the Open Source and Enterprise editions differ. The authentik pricing page lists enhanced audit logging and privileged access management as Enterprise features, so an entity that needs those capabilities for its evidence should confirm the edition and license terms in writing before the design is final. The repository code outside the enterprise directory is MIT licensed, but enterprise features fall under a separate license. Ask the vendor or your counsel to confirm which controls your evidence depends on, and build a fallback that exports authentication events to your own log platform if the Open Source edition is kept.
Where NIS2 scope and EU data transfer questions meet identity
This sequence helps you decide whether where identity data is hosted, who administers the platform remotely and where support staff sit create transfer or access obligations under GDPR Chapter V and the Data Act. It ends with a documented position for counsel to confirm.
Confirm NIS2 status of the entity
Establish whether your organization is an essential or important entity under NIS2 and which Member State transposition law applies to you. Your legal or compliance lead does this, because the classification drives how much of Article 21 and the 2024/2690 requirements you must evidence. The output is a written scope statement that names the sector, the classification and the national law, which the rest of the sequence uses as its starting point.
Map where identity data lives
List every place authentik stores or processes identity data for in-scope systems: the server and worker containers, the PostgreSQL database, backups, logs forwarded to a SIEM and any SaaS directory or application that receives provisioned accounts. Note the country or region of each location. The output is a data flow inventory that shows which components hold personal data and where that data is physically stored.
Identify remote and third-country access paths
Record every route by which someone outside the EU can reach or see identity data: vendor remote administration sessions, support engineers working from a third country, screen sharing during troubleshooting and cloud management consoles. EDPB Guidelines 05/2021 treat remote access from a third country, even only displaying data on a screen, as a transfer, so each path needs an entry. The output is an access path register that the team can hand to counsel.
Assess transfer triggers under GDPR Chapter V
With counsel, test each entry in the register against GDPR Article 44 and the EDPB Guidelines 05/2021 criteria, including cloud storage outside the EEA and remote display of data from a third country. Also review whether the hosting or support provider may face third-country legal demands, since EDPB Recommendations 01/2020 note that technical measures may not be effective where public authority powers exceed what is necessary and proportionate. The output is a documented transfer assessment per path, with a recorded decision and the legal basis relied on.
Check Data Act switching and government access terms
Review the contract with any provider of a data processing service against the Data Act. Confirm whether Article 32 government-access safeguards are described for non-personal data held in the Union, and whether switching rights under Articles 25, 29 and 50 are reflected, including the notice period, transition period and the ban on switching charges from 12 January 2027. Your legal team confirms the position. The output is a contract review note that lists gaps to raise with the provider.
Decide hosting and support boundaries
Based on the assessments, decide whether identity data stays within the EU, whether support access from outside the EU is restricted or prohibited, and whether a separate processor or hosting location is needed. Record each decision with an owner and the date it was made. The output is a signed boundary statement that the platform, security and legal teams all accept, which becomes the reference for later access reviews.
Record the position for counsel and auditors
Assemble the scope statement, data flow inventory, access path register, transfer assessments and boundary decision into one evidence pack. Ask counsel to confirm the conclusions, since DeployOpen does not give legal advice and NIS2 creates no certificate of compliance. The output is a reviewed file that supports supervisory questions from the national competent authority and any transfer questions from data protection authorities.
How DeployOpen scopes and delivers NIS2 identity controls
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including authentik. For NIS2 identity controls, we agree a written scope covering MFA by group and application, administrative credentials, identity lifecycle and failed login handling before any build starts.
How we scope
- Engagements are fixed-scope, with the authentik applications, groups and providers in scope agreed in writing before work starts.
- The written scope lists which applications and admin consoles must require MFA, and which user groups they apply to.
- We confirm the hosting model, identity sources and joiner, mover and leaver processes that feed authentik for the entity.
How we build
- We configure MFA stages in authentik flows and bind them to groups and applications so authentication strength matches the asset.
- Privileged administrators get separate accounts and stronger authenticators, with break-glass procedures tested before go-live.
- Lockout thresholds, session timeouts, password change rules and log forwarding are configured and tested against the written scope.
How we hand over
- You receive configuration documentation, an access register template and the evidence views your assessors will ask to see.
- We document operating procedures for account creation, role changes, deactivation and periodic access review.
- Handover includes a walkthrough of failed login and MFA event logs so your team can answer audit requests directly.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Security upgrades follow the authentik supported version policy, and we plan each upgrade against your written scope.
- Compliance readiness support prepares systems and evidence; independent auditors and national authorities make the final assessment.
