You need to investigate a risky sign-in, check whether a conditional access policy is enforcing, review application consent grants, and verify a PIM role activation — all within the next ten minutes. If you do not know where each of these capabilities lives in the Entra admin center, you waste time navigating menus during a time-sensitive operation. This subsection builds your navigation map so that every subsequent module can reference a location and you know exactly where it is.
Deliverable: Confident navigation of the Entra admin center with immediate access to every security-relevant blade. A bookmarked set of direct URLs for the locations you will use most frequently throughout this course.
⏱ Estimated completion: 10 minutes
Navigating the Entra admin center
The Entra admin center at entra.microsoft.com is the primary management interface for Entra ID. It replaced the legacy Azure Active Directory blade in the Azure portal, though many administrators still access identity settings through portal.azure.com out of habit. For identity security operations, the Entra admin center provides the most complete and organized view.
The center is organized into several main navigation sections. For identity security work, four areas account for the majority of your time: Protect & secure (conditional access, Identity Protection, authentication methods, named locations), Monitoring & health (sign-in logs, audit logs, diagnostic settings), Identity governance (PIM, access reviews, entitlement management), and Applications (app registrations, enterprise applications, consent grants).
Throughout this course, every subsection references specific portal locations. Here are the areas you will visit most frequently, organized by security function.
Conditional Access policies: entra.microsoft.com → Identity → Protect & secure → Conditional Access → Policies. This is where you create, edit, and monitor the policies that form the backbone of your identity security architecture. You will spend significant time here in EI3, EI4, and EI8.
Expand for Deeper Context
Sign-in logs: entra.microsoft.com → Identity → Monitoring & health → Sign-in logs. Four tabs: Interactive user sign-ins, Non-interactive user sign-ins, Service principal sign-ins, and Managed identity sign-ins. EI1 teaches you to read these fluently. Every subsequent module uses them for verification.
Risky users and risky sign-ins: entra.microsoft.com → Identity → Protect & secure → Identity Protection. The Risky users blade shows accounts that Identity Protection has flagged as potentially compromised. The Risky sign-ins blade shows individual authentication attempts that exhibited suspicious behavior. EI5 covers how to triage and respond to these.
Authentication methods: entra.microsoft.com → Identity → Protect & secure → Authentication methods → Policies. This is where you configure which authentication methods are available, who can use them, and the specific settings for each method (such as passkey profiles and number matching). EI2 covers this in detail.
Audit logs: entra.microsoft.com → Identity → Monitoring & health → Audit logs. Records every administrative action in Entra ID: policy changes, role assignments, consent grants, application modifications, and more. EI13 uses audit logs for detection rules.
PIM: entra.microsoft.com → Identity governance → Privileged Identity Management. The management interface for just-in-time access to privileged roles. EI6 covers PIM design and monitoring.
App registrations: entra.microsoft.com → Identity → Applications → App registrations. Lists every application registered in your tenant, with their credentials, permissions, and owners. EI9 covers application security.
Beyond the portal: PowerShell and Microsoft Graph
The Entra admin center is the visual interface, but every operation it performs uses the Microsoft Graph API underneath. For security operations at scale — querying sign-in logs across thousands of events, exporting conditional access policies for backup, auditing application permissions across hundreds of registrations — the portal is too slow. You need programmatic access.
Microsoft Graph PowerShell SDK (the Microsoft.Graph module) provides cmdlet access to every Entra ID operation. Throughout this course, key operations include Get-MgAuditLogSignIn for querying sign-in logs, Get-MgIdentityConditionalAccessPolicy for exporting conditional access policies, Get-MgApplication for auditing application registrations, and Get-MgRiskyUser for programmatic risk triage. When a module requires a PowerShell or Graph command, it will provide the exact syntax with annotation.
Expand for Deeper Context
KQL in Log Analytics is the query language you will use most frequently for verification and detection. When sign-in logs and audit logs are routed to a Log Analytics workspace (which EI14 covers), you can query them with KQL in the Sentinel workspace or through the Logs blade in the Entra admin center. Every "how do you verify it works" step in the Defense Design Method uses a KQL query. EI1 builds the foundational query skills.
Microsoft Graph REST API is available for automation scenarios where PowerShell is not appropriate — Logic Apps, Azure Functions, custom integrations. The same operations are available through direct HTTP calls. EI13 references the Graph API for automated detection and response workflows.
The course teaches both portal-based and programmatic approaches. Portal screenshots show you where things are. KQL queries and PowerShell commands show you how to operate at scale. A working identity security engineer needs both.
Roles and permissions for identity security work
Not every identity security operation requires Global Administrator. Understanding the minimum role required for each task prevents over-privileging security staff and supports the principle of least privilege that this course teaches.
Security Reader provides read-only access to sign-in logs, audit logs, Identity Protection, conditional access policies (view only), and security reports. This is the minimum role for SOC analysts performing identity alert triage and investigation. It does not allow any configuration changes.
Expand for Deeper Context
Security Administrator adds the ability to configure Identity Protection policies, manage security-related features, and read security reports. It does not grant the ability to modify conditional access policies or manage users.
Conditional Access Administrator provides the ability to create, modify, and delete conditional access policies and named locations. This is the role needed for deploying the conditional access architecture in EI3 and EI4. It is scoped specifically to conditional access — it does not grant access to user management or other directory functions.
Privileged Role Administrator manages PIM settings and role assignments. Required for EI6 (Privileged Identity Management) but not needed for other modules.
Application Administrator manages application registrations and enterprise applications. Required for EI9 (Application Registration Security) and consent governance.
Global Administrator has unrestricted access to all functions. In a well-designed environment, this role should be used only through PIM with just-in-time activation, and only when no lesser role is sufficient. EI6 covers how to design this.
For your developer tenant labs, you will have Global Administrator access by default. For production environments, the course notes which role is required for each operation so you can design your role assignments with least privilege.
Try it yourself
Try It — Navigate the Security Blades
Environment: Your M365 developer tenant.
Exercise: Open the Entra admin center (entra.microsoft.com) and navigate to each of the following locations. For each one, confirm you can find it and note what you see:
1. Conditional Access → Policies — are there any policies? (New dev tenants often have none.) 2. Sign-in logs — click the Interactive tab. Can you see recent sign-ins? 3. Authentication methods → Policies — which methods are enabled? 4. Identity Protection → Risky users — any users flagged? 5. Audit logs — filter by Activity: "Add conditional access policy" — any results? 6. App registrations → All applications — how many exist?
Navigating to each location should take you less than 60 seconds. If any location takes longer, practice the path until it is automatic. Every module in this course assumes you can find these locations without guidance.
⚠ Compliance Myth: "The Azure portal and Entra admin center show the same data"
The myth: I can manage Entra ID from either the Azure portal (portal.azure.com → Azure Active Directory) or the Entra admin center (entra.microsoft.com). They are the same interface.
The reality: Microsoft is migrating all identity management to the Entra admin center and has deprecated the Azure Active Directory blade in the Azure portal. While both currently show similar data, the Entra admin center receives new features first, has a more complete navigation structure for identity security, and is the long-term management surface. This course uses entra.microsoft.com exclusively. If you are still navigating to identity settings through the Azure portal, transition now — the Azure AD blade will eventually be removed entirely.
Decision point
You are reviewing NE's Entra ID security posture. You find 4 accounts with Global Administrator role, but NE's policy says maximum 2. The extra 2 were added during the AiTM incident for emergency response and never removed. Do you remove them?
Remove them — but through the proper process, not unilaterally. Notify the account owners that their emergency GA assignment is being revoked, confirm they have their standard role assignments restored, and document the removal with the rationale ('emergency assignment during INC-NE-2026-0227-001, no longer required'). Then add a PIR action item: 'Implement PIM time-limited role assignments for future incident response — emergency GA assignments auto-expire after 8 hours rather than persisting indefinitely.' The stale emergency assignment is a governance failure, not a technical failure — the fix is procedural.
NE's Entra ID security audit reveals: 4 Global Administrators (policy says 2), 23 users with Global Reader from a completed project, a break-glass account with no monitoring rule, and 3 guest accounts with no expiry date. Which finding is the highest priority?
The 4 Global Administrators — 2 extra GAs doubles the attack surface.
The break-glass account with no monitoring rule. The 4 GAs and stale Global Readers are governance issues that should be remediated — but they are existing conditions, not active threats. The unmonitored break-glass account is a critical detection gap: if the break-glass account is compromised or misused, the SOC has no alert. A break-glass account is excluded from CA policies by design — it is the most powerful and least restricted account in the tenant. Without monitoring, its compromise or misuse is invisible. Deploy the monitoring rule (any sign-in to the break-glass account = Severity 1 alert) before addressing the other findings.
The 23 stale Global Readers — this is the largest number of affected accounts.
The 3 guest accounts — external accounts without expiry are the highest risk.
You've mapped the identity threat landscape and learned to read sign-in logs.
EI0 established that every cloud attack starts with identity. EI1 took you through the signal that matters most — interactive, non-interactive, service principal, and managed identity sign-ins. Now you engineer the defences.
