Why NIS 2 Turns MFA From “Best Practise” to a Non-Negotiable Standard
A breach doesn’t distinguish between your senior IT admin and the accounts payable clerk-nor do today’s threat actors. Under NIS 2, your ability to verify every digital identity is no longer optional or just a checkbox for privileged accounts. Multi-factor authentication (MFA) now stands as the litmus test for genuine organisational resilience, demanded not just by the law, but by insurers, auditors, and your customers.
Regulators have made it clear: ENISA’s latest Threat Landscape report notes that over 70% of large breaches leverage basic credential theft-often beginning with regular users, not systems admins (ENISA 2023). The UK’s NCSC continues to warn that “credential stuffing and phishing” account for a majority of organisational breaches (NCSC). Gartner’s most recent industry review calls “password-only” approaches a compliance red flag in the European context (Gartner). The new standard is relentless: every identity should be verifiable, exceptions are scrutinised, and justification must be more than box-ticking.
Attackers exploit the overlooked, not just the overprivileged. Compliance now expects you to close every gap-no account left behind.
MFA is no longer just security theatre for IT staff-today, it’s how leading organisations signal maturity to the world.
Who Has To Use MFA Under NIS 2? Beyond Privilege, Into Real-World Risk
Most teams look for a binary answer: “Is MFA for everyone, or just the privileged?” The law is specific: MFA is non-negotiable for privileged accounts, but your risk register is what dictates where else it must apply-wherever there is real risk (ENISA NIS 2 Guidance).
So, who is “privileged”? ENISA spells it out: all admin, root, sysadmin, helpdesk, remote access, and privileged business process accounts are in-scope-no exceptions. But nuance matters-modern threats often target the “non-privileged” paths that grant escalation or access to sensitive data.
Your compliance hinges on addressing the following:
- Effective access: Who can affect which systems and data? Consider both direct and indirect roles.
- Location and access channel: Remote, mobile, or third-party access means elevated risk.
- Cloud, BYOD, and federated logins: Map and account for all access outside your “castle walls.”
- Current user inventory: If your staff or contractor list is static or out of date, you’ll struggle to convince any auditor.
Remember: “Enforced SSO with MFA” is only compliant when every in-scope account is enrolled, and your user list matches your real environment. Auditors are no longer swayed by vendor claims-they probe actual coverage and policy alignment.
NIS 2 isn’t one-size-fits-all; you must know-and show-the logic and living status behind every exception and inclusion.
Modern compliance is about risk-driven coverage-not blind uniformity, and certainly not wishful thinking.
Master NIS 2 without spreadsheet chaos
Centralise risk, incidents, suppliers, and evidence in one clean platform.
Segmentation, Not Suffocation: Good MFA Policy by Role and Risk
Pushing MFA everywhere without context leads to audit penalties or staff frustration. Leaders segment with intent. They balance risk, usability, and operational logic-then document their reasoning so audits can’t catch them exposed. Here’s how to visualise this for any organisation:
User Group MFA Segmentation Table
Intro: Use this table to document, justify, and operationalise MFA requirements for every key role-essential for audit.
| User Group | MFA Required? | How It’s Implemented | Reference |
|---|---|---|---|
| Admin/Root/SysOps | **Always** | Enforced SSO/IdP MFA, quarterly reviews | ISO 27001 A.8.5; NIS 2 |
| Remote Workers | **Yes-unless strictly justified** | MFA app/device trust, geo-fencing | ISO 27001 A.8.5; ENISA |
| Cloud Access Users | **Sensitive systems: Yes** | SSO+MFA, session logs, contextual training | ISO 27001 A.8.5; ENISA |
| Contractors/Suppliers | **Persistent: Yes; Episodic: Justify** | Validate & log; time-boxed, owned exceptions | ISO 27001 A.5.20; ENISA |
| General Staff | **Risk-based-document exceptions** | Log exclusions, detail compensating controls | ISO 27001 A.5.15; NIS 2 |
| SaaS/Third-Party Tools | **Depends on sensitivity** | SSO+MFA where feasible; periodic access reviews | ISO 27001 A.8.5; ENISA |
Most policies fail not on intent, but on brittle exceptions. Your defence is only as strong as your worst-justified exclusion.
Across Europe, agencies (ANSSI, BSI, AGID) have declared incomplete “role-only” MFA policies inadequate if they don’t track rationale for exclusions. Real compliance is segmentation plus traceable evidence.
Why Stale MFA Policies Are the Prime Audit Trap
Policy can’t stay frozen as your workforce, suppliers, and attack surface change. Auditors today expect living, version-controlled MFA documentation linked to active user inventories and workflow logs. A static annual policy review is now a serious audit risk.
Traceability Table: Bringing Policy to Life
Intro: Map every real-world trigger to its risk update and compliance artefact.
| Trigger | Risk Update | Control/SoA Link | Evidence Logged |
|---|---|---|---|
| New admin provisioned | High | ISO A.8.5 | MFA active, log archived, control owner |
| Risky SaaS onboarded | Medium | ISO A.5.20 | SSO+MFA on, contract checked |
| Third party/contractor add | Variable | ISO A.8.5/A.5.20 | Exception registered, logs stored |
| Staff role change | Recalculated | Policy A.5.15/8.5 | SoA/log shows new risk owner |
| Policy or staff change | Org-wide | All above | Staff acknowledges, review log |
If evidence isn’t being created at each event, controls and registers become paper shields-not real protection. Audits are lost not on lack of policy, but on lack of living proof.
Rhetorical lens: If you rely on “documented intent,” but can’t quickly prove current status, audit findings will follow.
Be NIS 2-ready from day one
Launch with a proven workspace and templates – just tailor, assign, and go.
Balancing Security with Staff Morale-The “MFA for All” Myth and Its Cure
There’s a persistent myth: universal MFA kills morale, creates support tickets, and pushes staff to circumvent controls. The truth? Transparent, risk-based MFA deployment-mixed with communication and real compensating controls-protects your audit position and promotes workforce trust.
Best-practise examples:
- MFA defaults “on” for high-risk systems, with clear, reviewable exceptions where tech or process gaps block universal enforcement.
- Contractors, suppliers, or users with only occasional access have time-boxed, owner-assigned exceptions. Owners review on offboarding, with all rationale logged.
- For lower-risk roles, document exactly why an exemption is granted (e.g., device bonding, session limitations, strict whitelisting), and set review intervals-avoiding auto-renewal of blind spots.
Audit standards now demand you treat the exception list as a living document. Show who approved, what the compensating control is, and when it will be reviewed next.
Audit stress drops when the exception list is small, owned, reviewed, and explained-not swept under the admin rug.
The badge of audit maturity is a lean, well-defended exception register-not an all-user or all-too-permissive policy.
Three Proofs Auditors Demand for MFA: Evidence Over Paper
Don’t let static policies lull you into audit false confidence. Modern auditors look for chain-of-evidence across all MFA controls. Here’s what boards and auditors now expect-across France (ANSSI), Germany (BSI), and UK/ENISA outlooks:
- Live account and user inventory-showing role, MFA status, review timing, and responsible owner.
- Exception register-detailing each exclusion’s rationale, compensating measures, and review owner and date.
- Workflow logs-every change to policy, user, or register creates an audit-ready event; staff acknowledgments and log-based evidence can be called by an auditor or board at any time.
These aren’t optional: they’re the “red lines” for demonstrating living controls. Auditors are clear-a shared drive folder or exported PDF of “who has MFA” is no longer sufficient.
Good audit outcomes come from showing compliance is a habit-not just a policy. Automate the review triggers, and let your ISMS do the heavy lifting.
Failing these proofs invites repeat findings, fines, or even formal investigation.
All your NIS 2, all in one place
From Articles 20–23 to audit plans – run and prove compliance, end-to-end.
Implementing Audit-Ready MFA: A Practical Loop for NIS 2 Survival
The goal is a self-documenting, living MFA workflow. For both leaders and practitioners, here’s your roadmap:
Step 1: Version control your compliance artefacts
Log every change to policies or registers; assign author, timestamp, and justification. Your ISMS or DMS must make every step retraceable.
Step 2: Secure and capture staff buy-in
Every staff/contractor must acknowledge the current MFA/access policy. Use digital prompts or e-signatures and capture as artefact.
Step 3: Automate risk-based triggers
Set automated reviews for any joiners, SaaS onboarding, or contractors. Reviewer, date, and outcome must link to control documentation.
Step 4: Aggregate your evidence
Build single-screen aggregation: users, MFA coverage, exceptions, versions, audit logs.
Step 5: Drill like an auditor
Quarterly, export role/MFA status, check the exception register, cross-verify staff acknowledgments, and verify events are linked to the Statement of Applicability.
Those investing in workflow tools that bridge policy, risk, and real-time register finds that audits become routine-no longer events to dread.
How ISMS.online Makes “Audit-Ready” an Achievable Default
The ISMS.online environment lets you centralise, operationalise, and surface every aspect of your MFA loop. Evidence is not lost in emails or “manual trackers”-it’s exportable, auditable, and readable by board, auditor, or regulator on demand.
Features enabling real audit readiness:
- Instant inventory: View, export, and drill through all users, roles, and MFA statuses.
- Exception register: See each exemption with live owner, rationale, compensating control, and due date-no lag or audit surprise.
- Evidence pack in one place: Aggregate acknowledgment logs, control histories, version audit trails, and risk registers with one click.
- Policy pack plus delivery: Assign, update, and track acknowledgement of MFA and access policies; monitor coverage across user groups.
- Automated onboarding triggers: When a new user appears or a contractor is onboarded, a workflow prompts immediate risk and MFA review, capturing all approval steps into the audit log.
Audit-readiness means anyone on your board or audit team can ask, and your ISMS instantly shows proof-no frantic human searching, just a living, compliance-proof system.
Identity CTA: When you lead the industry in real-time MFA and access control mapping, auditors and customers alike see your discipline as a signal of trust. Let ISMS.online hardwire that dominance in your routine. Build your living proof-and sleep easy when the auditor calls.
Frequently Asked Questions
What does NIS 2 mandate for MFA-is it just for admins or for every user who poses risk?
NIS 2 mandates Multi-Factor Authentication (MFA) as a hard requirement for all privileged and administrative accounts, but goes further by pressing organisations to apply MFA to any user profile whose access or working context is considered risk-elevating-not just IT admins. Your organisation must systematically map all users-including standard staff, contractors, temporary personnel, suppliers, and anyone with remote or cloud access-against business systems, data sensitivity, and exposure. Admin-only MFA is now obsolete: effective compliance demands a living risk assessment that drives who gets MFA, with technical enforcement, ongoing review, and formal documentation for every user tier.
Why can’t companies rely on admin-only MFA anymore?
Recent attack trends show that threat actors target the most accessible account, not just IT admin credentials. Regular staff with remote access, hybrid working patterns, or access to sensitive data are now frequent initial breach vectors. Under NIS 2, every foothold-any point where attackers could escalate-needs to be shielded by enforced MFA unless there’s a strong, regularly reviewed business rationale for exemption. Auditors evaluate how risk assessments lead to policy application across every user group, requiring evidence that this process is both deliberate and current.
How is “risk-based” MFA operationalised under NIS 2 and ENISA guidance?
“Risk-based” MFA is not theory: it’s formalised through methodical mapping of each user account to the risk landscape-combining access levels, data handled, remote/cloud work, and critical business functions. Here’s the real-world translation:
- Privileged/admin accounts: All require MFA by default-zero exceptions.
- Remote users/contractors/cloud/SaaS: Always within scope; MFA is a non-negotiable baseline.
- Standard, on-premises-only staff: May be exempt, but only with formal written rationale, assignment of a risk owner, review schedules, and compensating controls (e.g., stringent network segmentation or endpoint controls).
- Exceptions/legacy cases: Must be tracked in a master register, signed off by a named risk owner, regularly reviewed, and backed by evidence of why the exemption remains valid.
Without a “living risk inventory,” policy statements or intention-only controls are insufficient. Each time a new account is created, a role transitions, or a business tool is deployed, a risk review is required.
What changes for compliance and audits?
Auditors benchmark your real enforcement-registers, logs, SoA mapping-against what your policies claim. Any missing group or evidence gap can become an audit finding, especially if “risk-based” is just on paper. Ongoing, not static, coverage is the new normal.
Who must have MFA, who might, and when can you justify exemptions under NIS 2?
- Privileged/Admin Accounts: *Mandatory MFA*. This covers root, superuser, service accounts, privileged vendor logins, and any system-level administrator-no exceptions.
- Regular Users/Business Staff: *MFA is required* if roles involve access to sensitive systems, remote or cloud login, handling regulated data, or any system that could be leveraged for lateral movement in an attack. Whenever risk increases-a remote work enablement, new SaaS tool, or policy shift-the MFA net must expand.
- Contractors/Third-parties: Must follow the same mapping as insiders. If their accounts are long-lived, remote-enabled, or have elevated permissions, MFA applies as it would internally. Only local, strictly time-limited, non-privileged accounts not accessing critical assets may be considered for exemption-with rationale and expiry logged.
- True exemptions: Rare-only justified for accounts with no remote or critical system access. Must have a named owner and documented, time-bound review cadence.
Secure organisations treat every persistent digital identity as a potential attack vector, not just admin logins.
What are the most common NIS 2 MFA pitfalls, and how can you avoid them?
Frequent mistakes:
- Relying only on passwords for admins or remote/SaaS access.
- Policy statements that don’t match audit logs or real-world enforcement.
- Using SMS as a sole MFA mechanism despite public guidance against it (FIDO2, authenticator apps, or passkeys are now recommended).
- Failing to log/document exceptions or legacy accounts-if it’s not in the register with a reason and review cycle, it’s a gap.
- Forcing one-size-fits-all MFA strategies that spark user resistance and shadow IT (workarounds, personal device use).
- Letting registers and risk maps go stale-roles and systems change faster than old policy scripts.
Avoidance measures:
- Maintain a real-time inventory of all accounts, categorised by system risk and user type.
- Assign risk ownership for each exception, with tight documentation and follow-up.
- Periodically test your policy with self-audits and simulate an external assessment.
- Update MFA tools to meet the highest standard supported by your platforms and mobile workforce.
- Use platforms (like ISMS.online) that automate evidence collection, change triggers, and exception review reminders.
How can you structure evidence and mapping to pass an NIS 2 audit?
A resilient audit-ready approach uses a master register tying account types to risk level, MFA requirement, exception rationale, and evidence source. Example register:
| User Group | Risk Context | MFA Status | Audit Trail |
|---|---|---|---|
| Admin/Privileged | Any, always | Active by default | System event logs, config dump |
| Remote/SaaS Staff | Cloud/remote access | Active by default | User policy, adoption logs |
| Local-only staff | Internal, no SaaS/systems | Exempt (if justified) | Risk case, review doc |
| Vendors/Contractors | Persistent/sensitive data | Per mapped risk | Access logs, exception diary |
Key audit steps:
- For each exemption, record owner, rationale, expiry, and next review.
- Map every account type to your Statement of Applicability (SoA) and risk assessment controls.
- When roles, users, or tools change, ensure the platform prompts for a policy/control update-and logs evidence.
ISMS.online provides automated policy versioning, register tracking, and evidence logging-all exportable for auditors.
What documentation and operational processes are essential so your MFA policy survives the NIS 2 compliance audit?
Essentials:
- Version-controlled, living policy documents: Log every policy change, exception, and review-no static PDFs.
- Complete system and event logs: Track which accounts use MFA, who was covered at every point in time, and all exceptions.
- Centralised registers for user accounts and exceptions: Tie each account to risk evaluation, assigned owners, control status, and review scheduling-all updated in real time.
- Automated or workflow-based updates: Ensure any user/role or system addition triggers register/policy review instantly, not only at audit season.
- Regular self-checks/drills: Run quarterly self-tests simulating a regulatory audit: are all required accounts covered, are exemptions alive and reviewed, is your evidence chain intact-down to configuration levels if required.
When controls, exceptions, and evidence are woven into daily workflows-not just policy handbooks-compliance becomes not a pass/fail event, but a marker of ongoing business trust and maturity.
ISO 27001/NIS 2 MFA Compliance Table: From Expectation to Evidence
| Expectation | Operationalisation | ISO 27001/Annex A Reference |
|---|---|---|
| MFA for privileged/admin accounts is universal | Technical enforcement, logs, regular reviews | A.5.10, A.5.12, A.8.5 |
| Risk-based MFA rolled out to non-admin users | Role/inventory mapping, decision logs, risk reviews | A.8.3, A.8.9, A.5.12 |
| All exceptions formally reviewed/documented | Owner, justification, expiry, compensating controls | A.8.21, A.5.18, A.5.36 |
| Continuous review/evidence maintained | Self-audit, change logs, living SoA | A.5.35, A.9.2, A.9.3 |
Traceability Mini-Table
| Trigger | Risk Update | Control / SoA Link | Evidence Logged |
|---|---|---|---|
| Cloud app adopted | User risk reassessed | A.8.3, A.8.21 | Register change, MFA rollout log |
| Staff role goes remote | Privilege elevated | A.5.16, A.5.18 | Config change, onboarding logs |
| Exception reviewed/renewed | Control assessment | A.5.36 | Owner comment, review note |
Ongoing compliance comes when your access controls and MFA evidence are dynamic, role-by-role, and risk-mapped rather than static bureaucratic exercises. When every policy, system, and exception is tracked and tied to real-world evidence, audits become confidence-builders-not stress points-for your leadership and your board.
