NIS2 and Microsoft 365: the 10 gaps we find most often

Ten places in Microsoft 365 where companies most often lack exactly what the Czech Cybersecurity Act asks for. For each one: what the law wants, where it is configured and how to check it yourself.

The Czech Cybersecurity Act tends to be handled on paper. Risk analysis, policies, training, documentation. All of it is needed — but an inspection asks one more thing: show us how it is actually configured.

That is where it breaks. The paperwork is usually finished first, because a lawyer writes it in a month, while the configuration has to be walked through system by system and changed.

In a company of 30 to 200 people, most of that configuration lives in one place: Microsoft 365. Identity, mail, documents, laptops. Below are the ten things we find broken there most often. This is written in general terms — what companies commonly have wrong, not any customer's data. For each one: what the law asks for, what tends to be wrong, and how to check it yourself.

Why NIS2 comes down to Microsoft 365

The law says nothing about Microsoft. It talks about areas: multi-factor authentication, access control, monitoring and logging, protection against malware, cryptography, network and e-mail security, configuration management, roles and suppliers. But if your company runs on Microsoft 365, most of those areas are configured inside its admin centres — Entra ID, Exchange, Intune and Defender.

That makes Microsoft 365 the fastest place to find out where you really stand. The detailed mapping of the legal areas onto specific places in Microsoft 365 is on our NIS2 hub.

The ten gaps we find most often

1. Multi-factor authentication with exceptions

What the law asks for. Multi-factor authentication is named separately in the Act — having it "for most people" is not enough.

What tends to be wrong. The company rolled MFA out, but one excluded group stayed in the Conditional Access policies: the accounting software account, a service account, a director who complained, or an app where "it didn't work". The exception was meant to be temporary and has been there for years. An attacker only needs one.

How to check it. In Entra ID open Conditional Access and inspect the excluded users and applications on every policy. Then open the authentication-methods registration report and check how many accounts are not MFA capable — the target is zero. Exceptions that genuinely cannot be removed (an emergency account, for example) must be listed, time-limited and monitored.

2. Legacy sign-in left open

What the law asks for. Network and e-mail security — legacy protocols that cannot do a second factor should be switched off.

What tends to be wrong. Legacy sign-in via ActiveSync, IMAP or POP is still enabled, or SMTP AUTH is on for a printer that left the corridor three years ago. This is how MFA gets bypassed — the protocol cannot do a second factor, so a password is enough.

How to check it. In the Entra ID sign-in logs, filter by client app for Exchange ActiveSync and "other clients". Whatever shows up tells you who still uses it. SMTP AUTH is disabled organisation-wide in the Exchange admin centre and re-enabled only per mailbox, as an exception.

3. DMARC missing, or stuck on "p=none"

What the law asks for. The same area — e-mail security. And it is the one item on this list that anyone outside your company can see without logging in.

What tends to be wrong. Two variants. Either there is no DMARC record at all, or there is one with p=none, which means "send me reports but block nothing". The company assumes it is done, because a record exists in DNS. Meanwhile a spoofed e-mail in your director's name gets through exactly as before. Watch out for domains you don't send mail from — those are abused most often.

How to check it. List every domain the company owns and look at the TXT record _dmarc.yourdomain.com for each. The target is p=quarantine, ideally p=reject. SPF belongs on the same list. Our free on-line security audit does this part for you — it checks it from the outside.

4. Administrator accounts are not separated

What the law asks for. Access control and privileged accounts — highly privileged accounts need their own regime.

What tends to be wrong. The company's admin has one account for reading mail, browsing the web and running the entire tenant. When that account is stolen through ordinary phishing, the attacker didn't get one person's mailbox — they got the company. On top of that, an emergency "break-glass" account is often missing, so when sign-in breaks there is no way back in.

How to check it. Open roles in Entra ID and count your global administrators. More than five is almost certainly too many. Each of them should be a separate account with no mailbox and no licence, used only for administration. And verify that two emergency accounts exist and that someone has actually tested them — not just created them. Why companies end up fixing this under pressure is covered in Will your company survive the departure of its IT admin?

5. The audit log runs, but nobody checked for how long

What the law asks for. Monitoring and logging. Without records you cannot say what happened after an incident — and you will have to report a significant incident within 24 hours regardless.

What tends to be wrong. The unified audit log is on by default in new tenants, so the item gets ticked. Two things go unaddressed: how long records are kept, and whether some mailboxes are excluded from auditing. The standard tier keeps records for 180 days, which sounds generous — until you learn the attacker had been inside for eight months. The higher tier (part of E5, or a separate add-on) keeps key records for a year.

How to check it. In Purview open Audit and try searching for a sign-in six months old. Whatever cannot be found will not be available a year from now, either for an inspection or after an incident. Check specifically that no mailbox has audit bypass enabled.

6. Anyone can add an application

What the law asks for. Roles, responsibilities and suppliers — who is allowed to let an outside service into your environment.

What tends to be wrong. By default, an ordinary user can consent to a third-party application and grant it access to their mail or files. All it takes is clicking "allow" in a phishing e-mail. This kind of attack needs neither the password nor the second factor — the user grants access voluntarily, and MFA does nothing.

How to check it. In the Entra ID enterprise-application settings, review what users may consent to on their own and turn on the admin consent workflow. The same admin centre controls who may register applications, create groups and join devices.

7. External sharing in SharePoint and Teams without limits

What the law asks for. Access control — for every piece of data it should be clear who can reach it.

What tends to be wrong. "Anyone with the link" is still a common default. A link to the folder with your quotes then survives in a former colleague's mailbox, on a supplier's phone, or in a thread someone forwarded on. Nobody revokes it, because nobody knows it exists.

How to check it. In the SharePoint admin centre look at the sharing policies: what is the broadest permitted link type, and which type is offered by default. Then do the same for Teams and for calendar sharing. Limiting sharing to the domains you actually work with is worth doing too.

8. Disk encryption without stored recovery keys

What the law asks for. Cryptography and data protection.

What tends to be wrong. BitLocker on Windows and FileVault on Macs are enabled, but the key was never stored anywhere — it stayed with the device, or on a note in a drawer. That looks like a detail until a laptop locks itself and its owner is on holiday. The opposite variant also happens: keys are stored, but any user can read them, including for other people's devices.

How to check it. In Intune verify that encryption is enforced by policy rather than optional, and that recovery keys are escrowed centrally. Then in Entra ID check that the key is really there for a given device — and that not just anyone can display it.

9. Mail protection running on defaults

What the law asks for. Protection against malware.

What tends to be wrong. The company holds licences that include link and attachment scanning plus advanced anti-phishing, but nobody ever configured them beyond the default state. Attachments are not detonated in isolation, links are not rewritten, impersonation protection for specific people (typically the director) is set for nobody, and malicious mail that was already delivered is not pulled back out of mailboxes.

How to check it. In Defender for Office review the Safe Links, Safe Attachments and anti-phishing policies. For a smaller company the fastest route is to enable the Standard preset security policies and then add the names of the people who should be protected against impersonation.

10. Microsoft 365 backup: the recycle bin is not a backup

What the law asks for. Backup, business continuity and crisis management — an area that technical checks of Microsoft 365 configuration do not measure at all, yet the law requires it.

What tends to be wrong. A widespread assumption: "the data is in the cloud, Microsoft backs it up." Microsoft guarantees the availability of its service, not the recovery of your data after someone deletes or encrypts it. Recycle bins and retention are not a backup — they have their own limits and can roll over before you notice the problem. And even companies that buy Microsoft 365 backup have usually never tried a restore.

How to check it. Try restoring one mailbox and one SharePoint folder to its state 90 days ago. If it works and you know how long it took, you are done. If not, you have your first task for next week.

Where to start

Nobody does ten items at once. A sensible order:

This week: remove the MFA exceptions nobody can justify. Turn on admin consent for applications. Check DMARC on every domain.

This quarter: separate the administrator accounts and create (and test) two emergency ones. Disable legacy sign-in protocols. Tidy up sharing policies in SharePoint and Teams. Enable the preset policies in Defender. Test a restore and write down how long it took.

For every change, note the date and who approved it. An inspection doesn't only ask "do you have it?" but also "since when, and who decided?".

How to find out where you stand

Two routes, different vantage points.

From the outside, free: the on-line security audit checks what is publicly visible about your domain — SPF and DMARC, certificates, leaked passwords. Five minutes, no meeting. It covers item three from this list and the part that can be established without signing in.

From the inside, paid: the NIS2 Microsoft 365 audit for CZK 14,900 goes through roughly fifty specific settings against the areas of the Act, with read-only access. You get a list of what is fine, what is not, and in what order to fix it.

None of what is in this article needs us, though. You can go through all ten items yourself — Microsoft publishes the guides and you have access to the admin centres. You start needing someone the moment it has to be watched continuously. That is our entire commercial interest here; there is nothing else behind it.

Frequently asked questions

Is Microsoft 365 Business Premium enough?

For most of the ten items, yes — Business Premium includes Entra ID P1 (and therefore Conditional Access), Intune and Defender for Office mail protection. Two limits are worth naming: keeping audit records beyond 180 days needs a higher licence or an add-on, and no licence includes a Microsoft 365 backup. Missing features are rarely why companies fail, though. The usual reason is that what the licence does include was never switched on.

Do we need all of it even in the lower obligations regime?

The lower regime has a narrower scope and lighter formal requirements, but the areas are the same — multi-factor authentication, access, logging, backups. The difference is mostly in the depth of documentation and in what the authority will ask you to prove. We explain the difference between the regimes in plain language on the NIS2 hub.

Who has to approve this internally?

Management. The Act places responsibility for implementing the measures on company management, not on the IT administrator. In practice that means somebody has to sign off the list of changes and their deadlines — and "our IT guy didn't get to it" is not a defence. What has to be finished and by when is covered in NÚKIB registration is done. What you must finish before the deadline.

Can we do this ourselves?

A company with a capable administrator and some time, yes. The real obstacle is rarely expertise — it is that the changes affect people. Someone's old mail client stops working, someone has to start using an app on their phone, sharing links stops being unlimited. That is why these changes get postponed. What helps is giving them a deadline and an owner, not another tool.