Audit Entra ID before cloud identity drift becomes a breach
EtcSec runs 158 detections across 9 Microsoft Entra ID categories. The coverage focuses on the controls attackers abuse first in Microsoft 365 and Azure: Conditional Access gaps, missing MFA, risky permanent admins, dangerous app permissions, guest access sprawl, and weak response to risky users or risky sign-ins.
Collection uses Microsoft Graph API with application permissions only. No delegated session is required, no endpoint agent is installed, and the audit does not change the tenant.
The audit checks whether all users and admin roles are covered, whether MFA is enforced, whether legacy authentication is blocked, whether device compliance or token protection are used, and whether wide exclusions leave gaps.
The collector looks at PIM use, permanent assignments, emergency access accounts, approval and justification settings, activation duration, MFA on activation, and service principals holding admin roles.
The catalogue covers tenant-wide consent, admin consent policy, high-privilege Graph permissions, implicit grant, multi-tenant registrations, missing owners, expired secrets, and long-lived credentials.
Guest admins, unrestricted invitations, stale guest accounts, guest MFA gaps, cross-tenant trust, and B2B exposure are all part of the base Entra review rather than an optional annex.
The 9 categories line up with how cloud identity is actually abused
The Entra audit is not a generic cloud security score. It is a control review organised around Conditional Access, privileged access, application consent, guest governance, and risk-based response.
Identity and MFA
25 detections covering registration policy, strong authentication methods, passwordless readiness, stale user accounts, weak SSPR, and password protection.
Applications and service principals
24 detections covering dangerous Graph permissions, tenant-wide consent, app ownership, implicit grant, multi-tenant registrations, and secret hygiene.
Conditional Access
20 detections for coverage of all users and admins, MFA, legacy auth blocking, device compliance, risk-based policies, token protection, exclusions, and session controls.
Privileged access and PIM
18 detections covering PIM deployment, permanent assignments, break-glass accounts, approval, justification, MFA on activation, and Global Admin count.
Guests, groups, and config
39 detections covering guest access, cross-tenant trust, dynamic groups, role-assignable groups, app registration defaults, diagnostics, and tenant-wide consent settings.
Compliance and risk protection
18 detections covering P2 licensing, access reviews, Identity Protection posture, risky users, risky sign-ins, and automated response gaps.
Why teams use EtcSec for Entra ID reviews
Cloud identity changes constantly. A useful Entra audit needs to be repeatable after policy edits, app onboarding, mergers, external collaboration changes, and privileged access review cycles.
Read-only Graph workflow
The audit uses application permissions and Graph API reads. No delegated user session and no tenant mutation are required to produce the findings.
Fast enough to review after change windows
Typical runtime is 8 to 30 seconds depending on tenant size and Graph throttling. That supports recurring control review instead of annual-only snapshots.
Named detections aligned with operator tasks
Conditional Access owners, IAM teams, app platform owners, and security governance can each see the findings relevant to their control set instead of reading one blended cloud score.
One collector for cloud and on-prem identity
The same ETC Collector workflow can audit Active Directory and Microsoft Entra ID, which matters for hybrid programmes where drift in one plane amplifies risk in the other.
What a serious Entra ID security audit needs to make explicit
Cloud identity posture is often reduced to “do we have MFA?” The published Entra catalogue shows why that is too shallow: permission grants, tenant defaults, guest governance, and risk-response controls all interact.
Read-only Graph collection and the endpoints that matter
The audit reads `/users`, `/groups`, `/applications`, `/servicePrincipals`, `/identity/conditionalAccess/policies`, `/roleManagement/directory`, `/policies/authorizationPolicy`, and relevant audit or identity protection endpoints. That matters because the findings can be traced back to concrete policy objects or app registrations rather than vague cloud posture claims.
Using application permissions also means the workflow is appropriate for automated or recurring review. Security teams do not need to sign in interactively every time they want to test whether a policy still protects all admins or whether new app registrations introduced dangerous consent paths.
The 9 categories and the operator questions they answer
| Category | Checks | What the operator learns |
|---|---|---|
| Identity | 25 | Whether MFA, password policy, SSPR, registration, and stale-account controls are strong enough for modern phishing and credential attacks. |
| Applications | 24 | Whether app registrations, service principals, consent, and credentials grant excessive access or hide orphaned risk. |
| Conditional Access | 20 | Whether policy coverage is complete for all users, admins, legacy protocols, risky sign-ins, and session control. |
| Privileged Access | 18 | Whether PIM is used correctly, break-glass accounts exist, and permanent admin assignment is still common. |
| Guest External | 15 | Whether guest users, invitations, and cross-tenant collaboration are constrained and reviewable. |
| Config | 12 | Whether tenant-wide defaults, diagnostics, app registration, and consent settings support secure operation. |
| Groups | 12 | Whether dynamic, role-assignable, or externally owned groups create hidden privilege or governance gaps. |
| Compliance | 8 | Whether the tenant is licensed and configured for access reviews, Identity Protection, and governed access. |
| Risk Protection | 10 | Whether risky users and risky sign-ins are detected and automatically acted upon. |
Detection families that usually trigger remediation
Conditional Access coverage gaps
Key findings include CA_NO_MFA_REQUIREMENT, CA_NO_POLICY_ALL_USERS, CA_NO_POLICY_ADMINS, CA_NO_LEGACY_AUTH_BLOCK, CA_NO_DEVICE_COMPLIANCE, CA_NO_RISK_BASED_SIGNIN, and CA_POLICY_REPORT_ONLY.
- Shows whether the tenant relies on partial policy coverage.
- Separates risk-based controls from baseline MFA enforcement.
- Makes policy exclusions visible instead of hidden in JSON.
Privileged access drift
PA_PIM_NOT_ENABLED, PA_PERMANENT_ADMIN_ASSIGNMENTS, PA_NO_EMERGENCY_ACCOUNTS, PA_GLOBAL_ADMIN_NOT_MFA, PA_TOO_MANY_GLOBAL_ADMINS, and PA_SERVICE_PRINCIPAL_ADMIN define whether privileged access is still standing and weakly protected.
- Useful for IAM, cloud platform, and governance owners.
- Breaks down emergency access design separately from PIM hygiene.
- Highlights service principal privilege because MFA cannot compensate there.
Application consent and credential risk
APP_USER_CONSENT_UNRESTRICTED, APP_DANGEROUS_PERMISSION_DIR, APP_DANGEROUS_PERMISSION_ROLE, APP_NO_OWNER, APP_SECRET_EXPIRED, APP_SECRET_LONG_EXPIRY, and SP_HIGH_PRIVILEGE expose the most common escalation and data-exposure paths.
- Combines app registration review with service principal posture.
- Surfaces credential hygiene, not just permission names.
- Supports app-owner clean-up work after mergers or cloud sprawl.
Guest and cross-tenant governance
GUEST_ADMIN_ROLE, GUEST_NO_MFA_REQUIRED, GUEST_INVITATION_UNRESTRICTED, B2B_CROSS_TENANT_OPEN, GUEST_STALE_90_DAYS, and GUEST_NO_ACCESS_REVIEW explain whether collaboration remains bounded.
- Especially relevant in M&A or partner-heavy environments.
- Separates invitation policy from actual stale guest population.
- Shows where guest access is present in privileged or security groups.
Identity Protection and response gaps
RISK_NO_SIGNIN_RISK_POLICY, RISK_NO_USER_RISK_POLICY, RISK_HIGH_RISK_USERS_ACTIVE, RISK_LEAKED_CREDENTIALS, and RISK_USERS_NOT_REMEDIATED show whether the tenant can react when Microsoft marks a user or sign-in as risky.
- Important because detection without response still leaves active compromise unresolved.
- Ties licensing and policy configuration to operational response.
- Helps distinguish raw telemetry from enforced protection.
How the findings map to real ownership boundaries
Conditional Access owners usually care about the CA category, but their settings also determine whether admins, guests, or risky users are protected. Application platform owners need the Applications findings because consent and service principal privilege are often introduced outside central IAM workflows. Governance owners look at Compliance and Risk Protection because those categories reveal whether PIM, Identity Protection, and access reviews are actually being used rather than merely licensed.
A useful Entra landing page therefore needs to do more than say “we audit Entra ID”. It should show how the findings attach to concrete operating models: app onboarding, admin role assignment, partner collaboration, risk-response automation, and hybrid identity oversight.
- IAM and cloud engineering own Conditional Access and PIM decisions.
- App platform teams own registration sprawl, owners, and secret rotation.
- Security governance owns access reviews, compliance evidence, and risk response.
- Hybrid identity programmes need cloud and on-prem findings in one workflow.
Why the collector matters even for a cloud-native review
The published collector documentation makes a useful point: the workflow is not split into a completely separate cloud product and on-prem product. The same collector can query Graph for Entra and LDAP or SMB for Active Directory. That matters because many hybrid identity issues are compound problems. An on-prem service account with stale privilege and a cloud admin account without MFA can both contribute to the same escalation narrative.
EtcSec adds the dashboard and operating layer on top of the collector. The result is a path from raw cloud control review into recurring remediation and historical tracking rather than a one-off CSV or checklist exercise.
Frequently asked questions
What does the Entra ID audit actually cover?
The published catalogue lists 158 detections across Identity (29), Applications (28), Conditional Access (20), Privileged Access (24), Guest External (15), Config (12), Groups (12), Compliance (8), and Risk Protection (10).
Does the audit require delegated permissions or an interactive admin session?
No. The review is built around Microsoft Graph application permissions and does not require an interactive delegated sign-in. That keeps the workflow automation-friendly and avoids the need to impersonate a user.
Can I review Entra and Active Directory in the same workflow?
Yes. ETC Collector supports both Entra ID and Active Directory so hybrid identity teams can run both reviews through one collection model and one operating workflow.
Why are application permissions and guest governance treated as first-class findings?
Because many real-world cloud identity incidents start with consent phishing, excessive Graph permissions, stale service principals, or weak guest collaboration defaults rather than only with a missing MFA checkbox.
Related identity security pages
Review the on-prem catalogue that complements the Entra control review for hybrid identity programmes.
Inspect the named detections that power the cloud and on-prem audit pages.
Understand the collection workflow, standalone mode, daemon mode, and API surface.
Compare the open-source collection engine with the SaaS layer for dashboards and follow-up.
Start your Microsoft Entra ID audit
Connect with read-only Graph permissions, review Conditional Access, privileged access, applications, guests, and risk controls, and turn the output into recurring remediation work.