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
Critical
- What it checks
- Every account holding a privileged directory role (Global Administrator, Privileged Role Administrator, and the other high-impact roles) is registered for a strong second factor — Authenticator app, FIDO2 key, or Windows Hello — and is covered by a conditional access policy that enforces MFA at sign-in.
- Why it matters
- An admin without MFA is the single most common path to a full tenant takeover. A leaked or phished password is often enough on its own. Most regulators and insurers treat this as a non-negotiable baseline.
- 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 accounts permanently assigned the Global Administrator role. Microsoft's own guidance is fewer than 5 (and ideally 2 to 4). Cindera flags this when it goes above that threshold or when admin accounts are also used for daily work.
- 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 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
Excessive guest accounts
Medium
- What it checks
- Guest (B2B) accounts in the tenant, particularly those that haven't signed in for 90+ days or that hold direct directory-role assignments. Cindera flags guests with privileged access as elevated severity.
- Why it matters
- Guests are often added for a one-off project and never removed. Over time, external users accumulate access that no internal owner can account for — exactly the kind of finding that surfaces during a partner security questionnaire or breach forensics.
- Compliance mapping
- NIS2-21.2.iGDPR-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
- The presence of one or two clearly identified emergency-access (break-glass) accounts, that they are excluded from the org-wide MFA policy as expected, but covered by a separate strong-authentication policy (FIDO2 or certificate). Flags both the absence of break-glass accounts and unsafe configurations.
- 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