Cindera · Scan Rules
Scan Rules
Cindera runs 14 identity and access security checks against your Microsoft 365 tenant. Each finding is mapped to NIS2 and GDPR controls so you can take the same evidence to your auditor or insurer.
How to read this page
Every rule lists the severity range it can emit, what it actually looks at inside your tenant, why it matters in plain language, and which compliance controls it maps to. Most rules emit a single severity. A few scale severity with the size of the finding. Those show a range.
Rule 01
Admin MFA strength
CriticalHighMedium
- What it checks
- How strong the second factor on each privileged account actually is, not merely whether one exists. No method at all is critical. A phone number as the only method is high, because SMS and voice can be taken over without the account holder doing anything. An authenticator app with nothing stronger registered is medium: it stops a leaked password but not a real-time relay. An account with FIDO2, Windows Hello for Business or certificate-based authentication passes.
- Why it matters
- An admin without MFA is the single most common path to a full tenant takeover, and a leaked password is often enough on its own. The distinction between phishable and phishing-resistant methods matters just as much now: attacker-in-the-middle kits that capture a password and an app approval together are sold as a service, and insurers have begun asking which methods administrators actually use.
- Compliance mapping
- NIS2-21.2.dNIS2-21.2.jGDPR-32
Rule 02
Legacy authentication blocking
Critical
- What it checks
- At least one conditional access policy is in the on state and blocks legacy authentication protocols (Exchange ActiveSync basic auth, IMAP, POP, SMTP AUTH, MAPI over HTTP, and older Office clients).
- Why it matters
- Legacy protocols don't support MFA. They pre-date it. As long as they're allowed, every other MFA control can be bypassed by sending the same password to a legacy endpoint. Microsoft has been retiring these protocols, but tenants still routinely have at least one open path.
- Compliance mapping
- NIS2-21.2.dNIS2-21.2.jGDPR-32
Rule 03
Excessive Global Administrators
High
- What it checks
- The number of enabled accounts permanently assigned the Global Administrator role. Microsoft's own guidance is to keep this small, between 2 and 4. Cindera raises a finding above 3 and lists every Global Administrator by name.
- Why it matters
- Every Global Admin is a critical asset. Too many of them increases your blast radius. One compromised admin is enough to ransom a tenant. Mid-sized tenants commonly accumulate Global Admins over time without a cleanup.
- Compliance mapping
- NIS2-21.2.iGDPR-32
Rule 04
Dormant privileged accounts
High
- What it checks
- Accounts that hold a privileged role but have not signed in for at least 90 days. Cindera uses the sign-in activity from Microsoft Graph and reports the named users with their last activity timestamp.
- Why it matters
- Dormant admin accounts are attractive targets. They often have stale passwords, no MFA monitoring, and nobody notices when they're used. Removing or de-privileging them costs nothing and meaningfully shrinks your attack surface.
- Compliance mapping
- NIS2-21.2.iGDPR-32
Rule 05
Risky app consents
High
- What it checks
- Third-party applications consented in your tenant with high-impact delegated or application permissions, especially Mail.ReadWrite, Files.ReadWrite.All, and Directory.ReadWrite.All granted to apps from unverified publishers.
- Why it matters
- Consent phishing is now a dominant initial-access technique. An attacker tricks one user into granting a malicious OAuth app. No password ever leaves the user, and from there the app reads mail, exfiltrates files, or pivots into other tenants.
- Compliance mapping
- NIS2-21.2.eGDPR-32
Rule 06
Expiring client secrets
HighMedium
- What it checks
- Application client secrets and certificates that will expire within the next 30 days (High) or 90 days (Medium). Includes which application owns each credential and the exact expiry date.
- Why it matters
- An expired secret quietly breaks production integrations (mail-sending, document automation, ticketing webhooks), and the on-call response is usually a hot rotation under pressure. Surfacing this early lets you rotate on a planned change window.
- Compliance mapping
- NIS2-21.2.i
Rule 07
Effective MFA exposure
MediumHighCritical
- What it checks
- Who is still exempt from MFA once every enforcing policy is taken into account. Cindera resolves each policy's exclusions (named users, excluded directory roles, and exclusion groups expanded through their nested groups) and reports the users left uncovered by all of them, by name. Break-glass accounts, disabled accounts and guests are excluded from the result.
- Why it matters
- A policy called 'Require MFA for all users' reads as fully covered in the Entra portal while an exclusion group created years ago quietly exempts part of the organisation, often including an administrator. Entra shows exclusions per policy and registration state per user, but never the two intersected across every policy, which is the only view that answers who can actually sign in with a password alone.
- Compliance mapping
- NIS2-21.2.dGDPR-32
Rule 08
Enforced MFA policy
High
- What it checks
- A conditional access policy is in the on state that requires multi-factor authentication for all users (with documented exclusions only). The Microsoft security defaults toggle also satisfies this check on smaller tenants.
- Why it matters
- Per-user MFA registration is necessary but not sufficient. Without an enforcing policy, users can register MFA and still sign in without it from a permitted location or app. A blanket conditional access rule is the control auditors and insurers want to see.
- Compliance mapping
- NIS2-21.2.dNIS2-21.2.jGDPR-32
Rule 09
Overprivileged service principals: tier-0 Graph permissions
MediumHighCritical
- What it checks
- Service principals (typically applications and automation identities) holding application-level Graph permissions that grant tenant-wide read/write, such as Directory.ReadWrite.All, RoleManagement.ReadWrite.Directory, or Application.ReadWrite.All. Severity scales with the blast radius of the permission and the publisher.
- Why it matters
- A service principal with Directory.ReadWrite.All can do almost anything a Global Admin can do, and rarely has the same MFA, monitoring, or sign-in restrictions. These are some of the most attractive targets for an attacker who has compromised a developer machine.
- Compliance mapping
- NIS2-21.2.eNIS2-21.2.iGDPR-32
Rule 10
Permanent privileged role assignments (PIM)
High
- What it checks
- Directory-role assignments that are active permanently rather than activated just-in-time through Privileged Identity Management. Cindera lists the assignments and the roles involved.
- Why it matters
- Just-in-time activation shrinks the window during which a privileged account is actually privileged, which directly limits the impact of credential theft. NIS2 and several insurer questionnaires now ask explicitly about JIT/PIM use for tier-0 roles.
- Compliance mapping
- NIS2-21.2.iGDPR-32
Rule 11
Break-glass account hygiene
MediumHigh
- What it checks
- Whether the tenant has clearly identified emergency-access (break-glass) Global Administrators, and whether any of them is subject to an enforced conditional access policy. Cindera flags three cases: no break-glass account at all, only one where two are recommended, and a break-glass account that an enforced MFA or block policy would lock out. Detection is based on standard emergency-access naming conventions.
- Why it matters
- Break-glass accounts are how you recover the tenant if everything else fails, including your identity provider. Microsoft publishes a specific configuration for them; getting it wrong either locks you out during an incident or leaves a permanent backdoor.
- Compliance mapping
- NIS2-21.2.cNIS2-21.2.i
Rule 12
Service principals without owner
Medium
- What it checks
- Application registrations and service principals with no assigned owner. Cindera reports the application name, app ID, and creation date so you can locate who actually uses them.
- Why it matters
- An ownerless app is one nobody is responsible for, nobody to notify when its certificates expire, nobody to question if its permissions should still be there. They're a common source of stale, over-permissioned identities that survive employee turnover.
- Compliance mapping
- NIS2-21.2.iGDPR-32
Rule 13
Conditional access policies stuck in report-only
Medium
- What it checks
- Conditional access policies left in the report-only state for more than 30 days. Cindera lists each affected policy and how long it has been in report-only.
- Why it matters
- Report-only is a useful staging mode but it provides no protection, only telemetry. Policies parked there for months indicate either an abandoned rollout or a configuration nobody is confident enough to enable. Either way, your CA posture is weaker than it looks on paper.
- Compliance mapping
- NIS2-21.2.dNIS2-21.2.j
Rule 14
MFA registration coverage
MediumHighCritical
- What it checks
- The percentage of active users registered for a strong MFA method. Severity scales with the gap: a small backlog among newly created users is Medium, while large gaps or privileged users without MFA registered are High to Critical.
- Why it matters
- Even with an enforced MFA policy, unregistered users can be exploited during the registration grace window, for example via the well-known 'register an attacker's authenticator' attack. Closing the registration gap removes that path entirely.
- Compliance mapping
- NIS2-21.2.dGDPR-32
Rule 15
Administrative account separation
HighMedium
- What it checks
- Whether privileged accounts are separate identities or everyday ones. Two deviations are reported: an administrator synchronised from on-premises Active Directory rather than created in the cloud, and an administrator carrying assigned licences, which means mail and files sit on the same identity as the administrative rights. Break-glass accounts are excluded from both checks.
- Why it matters
- A synchronised administrator means whoever compromises your on-premises domain inherits the cloud tenant, with no further attack required; Microsoft's own tier model puts cloud administration outside that blast radius for exactly this reason. A licensed administrator is an account somebody reads mail on, which makes every phishing attempt an attempt on the directory rather than on one mailbox. Neither is a misconfiguration in the ordinary sense, which is why nobody revisits them.
- Compliance mapping
- NIS2-21.2.iNIS2-21.2.jGDPR-32
Rule 16
Cross-tenant trust
CriticalHighMedium
- What it checks
- The trust your tenant extends to other Microsoft 365 organisations. Three settings are reported: accepting a partner's multi-factor claim instead of challenging their users yourself, accepting their device compliance claims, and allowing a partner to synchronise user accounts into your directory.
- Why it matters
- Every other check here asks whether your own controls are correct. These ask whose controls you have agreed to accept instead. Trusting a partner's MFA claim makes your requirement exactly as strong as theirs, and you cannot inspect theirs. Inbound synchronisation goes further and lets another organisation create identities inside your security boundary. Both are usually configured once for convenience during a project and never looked at again.
- Compliance mapping
- NIS2-21.2.dNIS2-21.2.iNIS2-21.2.jGDPR-32
Rule 17
Ownership of privileged objects
CriticalHigh
- What it checks
- Users who own something privileged without holding a privileged role themselves. Three cases: the owner of a group excluded from an enforced MFA policy, the owner of a service principal holding tier-0 Graph permissions, and the owner of a group that can carry a directory role. Owners who already hold a privileged role are not reported, since they can do this directly anyway.
- Why it matters
- Every membership audit answers who is in a group or who holds a role. An owner appears in neither and can put themselves into both, so a role review that looks clean can still be wrong. The owner of an MFA exclusion group can exempt themselves from multi-factor authentication in one click; the owner of an application can add a credential and then act as that application with all of its permissions. Neither action requires approval, and both look like ordinary maintenance in the audit log.
- Compliance mapping
- NIS2-21.2.dNIS2-21.2.eNIS2-21.2.iGDPR-32
Rule 18
Tenant-wide default permissions
HighMedium
- What it checks
- Settings Microsoft ships switched on and almost nobody revisits: whether any employee can approve an application's access to their own data, whether guests see the directory as an employee does, whether any user can register an application or create a new tenant, whether anyone including guests can invite further guests, and whether the tenant is relying on security defaults instead of Conditional Access.
- Why it matters
- A customer can describe every policy they configured, and none of these, because configuring them was never a step anyone took. Unrestricted user consent is the illicit consent grant: the attack that needs no password, survives a password reset and is not stopped by MFA. Member-equivalent guest access hands every external account your full user list and org chart, which is the reconnaissance a targeted phishing campaign runs on. Neither shows up in a policy review because neither is a policy.
- Compliance mapping
- NIS2-21.2.eNIS2-21.2.iNIS2-21.2.jGDPR-32GDPR-5
Rule 19
Credentials on privileged applications
HighMedium
- What it checks
- The client secrets and certificates held by applications with tier-0 Graph permissions. Three things are reported: a credential added within the last two weeks, more than two live credentials on one application, and a credential valid for longer than a year. Certificates are included, not only secrets.
- Why it matters
- Adding a credential to a privileged application is the ordinary way to make access durable. It belongs to no person, so it survives a password change, an MFA rollout and the departure of whoever created it, and it produces no sign-in that looks unusual. It is also exactly what a routine rotation looks like, which is why the finding asks you to confirm which of the two happened rather than announcing a compromise. The expiring-secrets rule answers the separate, operational question of what is about to stop working.
- Compliance mapping
- NIS2-21.2.eNIS2-21.2.iGDPR-32
Rule 20
MFA enforcement in practice
CriticalHigh
- What it checks
- The share of real sign-ins over the last 30 days that completed with a single factor, on tenants whose configuration claims multi-factor authentication is required for everyone. Only interactive sign-ins are counted, and the rule stays silent below fifty of them.
- Why it matters
- Every other check reads configuration and reasons about what it should produce. This one reads the outcome. A policy can be correct and still not apply: an exclusion group added for a migration, a trusted location covering an entire ISP range, a policy scoped to selected applications, or a legacy protocol that bypasses Conditional Access altogether. All of those look fine in the policy blade, and the sign-in log is the only place the difference shows. It is also the number an auditor or insurer is really asking about when they ask whether MFA is enforced. Requires Entra ID P1, and stays silent rather than reporting a clean result when the log cannot be read.
- Compliance mapping
- NIS2-21.2.dNIS2-21.2.jGDPR-32