Lab 03 — Identity Security

Identity is one of the most important security layers in Microsoft environments.

A user may be:

Inside the Office

Working Remotely

Using a Mobile Device

Using a Managed Laptop

Accessing Microsoft 365

Accessing Azure

Accessing SaaS Applications

The security decision is no longer simply:

Is the User on the Corporate Network?

A better question is:

Who Is the User?

How Did They Authenticate?

What Device Are They Using?

What Are They Trying to Access?

What Privilege Do They Have?

Is the Activity Risky?

In this lab, you will assess identity security from an enterprise defender’s perspective.

Mission Information

Lab: Identity Security
Level: Beginner → Intermediate
Estimated Time: 150–210 minutes
Environment: Authorized Microsoft Entra ID / Microsoft 365 training tenant
Primary Role: Identity Security Engineer
Supporting Roles: IAM Engineer, Microsoft Security Engineer, SOC Analyst, Cloud Security Engineer, Security Consultant

Mission Scenario

Your organization has recently expanded its Microsoft cloud environment.

The tenant now contains:

Employees

Administrators

Contractors

Guest Users

Enterprise Applications

Cloud Workloads

The security team wants to verify that identity access is appropriately controlled.

You have been asked to review:

Users

Groups

Authentication

MFA

Conditional Access

Administrative Roles

Privileged Access

Guest Users

Applications

Workload Identities

Sign-In Activity

Audit Activity

Identity Risk

Your goal is to identify:

Excessive Access

Weak Authentication

Standing Privilege

Stale Identities

Uncontrolled Guest Access

Over-Privileged Applications

Suspicious Sign-In Activity

Learning Objectives

By completing this lab, you should be able to:

• Understand Microsoft Entra ID identity structure
• Review users
• Review groups
• Review account lifecycle
• Review authentication methods
• Understand MFA coverage
• Review Conditional Access
• Review administrative roles
• Identify standing privilege
• Understand privileged-access management
• Review guest identities
• Review application identities
• Understand enterprise applications
• Review workload identities
• Review sign-in activity
• Review audit activity
• Understand risky users and risky sign-ins conceptually
• Identify identity-security findings
• Prioritize remediation
• Build an identity-security assessment report

Identity Security Mental Model

Think:

IDENTITY
   ↓
AUTHENTICATION
   ↓
CONTEXT
   ↓
ACCESS POLICY
   ↓
AUTHORIZATION
   ↓
RESOURCE
   ↓
MONITORING
   ↓
REVIEW

For privileged identities:

ELIGIBLE
   ↓
VERIFY
   ↓
ACTIVATE
   ↓
USE
   ↓
MONITOR
   ↓
EXPIRE

Lab Architecture

                     USERS
                       |
                       v
              Microsoft Entra ID
                       |
        +--------------+--------------+
        |              |              |
        v              v              v
 Authentication      Groups         Roles
        |              |              |
        +--------------+--------------+
                       |
                       v
                Access Policies
                       |
          +------------+------------+
          |            |            |
          v            v            v
     Microsoft 365   Azure       SaaS Apps
          |
          v
      Security Logs
          |
          v
   Monitoring / Review

Part 01 — Establish the Assessment Scope

Before reviewing anything, define:

Tenant

Business Unit

User Population

Administrative Roles

Applications

Time Period

Data Sensitivity

Document:

Tenant Name:

Assessment Owner:

Assessment Date:

Scope:

Excluded Systems:

Primary Contacts:

Why Scope Matters

An identity assessment should not become:

Review Everything

without understanding:

Business Context

Authority

Critical Resources

Relevant Identities

Part 02 — Understand Identity Types

Microsoft environments may contain multiple identity types.

Examples:

Employees

Administrators

Guests

Service Accounts

Applications

Managed Identities

Automation Identities

Your first task is to understand:

WHO EXISTS?

Identity Inventory Model

For every identity capture:

Name

Type

Owner

Purpose

Enabled State

Privilege

Authentication

Last Review

Part 03 — Review Users

Using the Microsoft Entra admin center or other approved administrative interface, review the user inventory.

Record:

Display Name

User Principal Name

User Type

Account State

Department

Manager

Created Date

Last Sign-In Where Available

Security Questions

For each user ask:

Is This User Still Active?

Does the Identity Have an Owner?

Is Their Access Appropriate?

Are They Privileged?

Is Their Authentication Strong Enough?

Part 04 — Identify Enabled Accounts

Separate:

Enabled Users

Disabled Users

An enabled identity should have:

Business Need

Known Owner

Expected Activity

Finding Example

Finding:
Unnecessary Enabled User Account

Observation:
An identity associated with a former or
inactive business relationship remains
enabled.

Risk:
Unused credentials may provide an
unnecessary path to corporate resources.

Recommendation:
Validate current ownership and disable the
identity if there is no active business
requirement.

Part 05 — Review Account Lifecycle

Identity lifecycle should follow:

JOIN
 ↓
PROVISION
 ↓
ASSIGN ACCESS
 ↓
REVIEW
 ↓
CHANGE
 ↓
DEPROVISION

Joiner Review

For new users verify:

Manager Approval

Correct Department

Correct Groups

Minimum Access

Required Applications

Mover Review

When users change roles:

REMOVE OLD ACCESS
      ↓
ADD NEW ACCESS

Do not simply:

ADD NEW ACCESS

while keeping everything old.

Leaver Review

For departing users consider:

Disable Access

Revoke Sessions

Remove Privilege

Transfer Required Data

Remove Group Membership

Complete Offboarding

Part 06 — Review Dormant Accounts

Where appropriate, identify identities with no expected recent activity.

A dormant account may indicate:

Former Employee

Unused Contractor

Old Test Identity

Abandoned Administrative Account

Important

Do not automatically remove an account purely because it has not signed in recently.

Validate:

Business Purpose

Service Dependency

Leave Status

Emergency Function

Part 07 — Review Groups

Groups can control access to:

Applications

Resources

Administrative Functions

Microsoft 365 Services

Review:

Group Name

Group Type

Members

Owner

Purpose

Assigned Resources

Group Security Model

USERS
  ↓
GROUP
  ↓
RESOURCE

Part 08 — Review Group Ownership

Ask:

Does Every Important Group Have an Owner?

Does the Owner Understand the Group's Purpose?

Is Membership Reviewed?

Groups without clear ownership can become:

Access Accumulation Points

Part 09 — Review Group Membership

Select sensitive groups and review all members.

Look for:

Unexpected Users

Guests

Former Employees

Administrative Accounts

Nested Access

Excessive Membership

Finding Example

Finding:
Excessive Security Group Membership

Observation:
Users retain membership in a security group
after their original business requirement
has ended.

Risk:
The users may continue to access resources
outside their current responsibilities.

Recommendation:
Perform an access review and remove
membership that is no longer required.

Part 10 — Authentication Review

Authentication answers:

Who Are You?

Review which authentication methods are used across the organization.

These may include:

Passwords

Authenticator Applications

Security Keys

Certificates

Biometric Methods

Passwordless Authentication

Authentication Assessment Questions

Ask:

Which Methods Are Allowed?

Which Methods Are Preferred?

Which Users Have Strong Authentication?

Which Privileged Users Have Weak Methods?

How Is Recovery Managed?

Part 11 — Review MFA Coverage

Identify whether MFA is required for:

Administrators

Remote Access

Sensitive Applications

High-Risk Users

General Workforce

Security Priority

At minimum, privileged identities should receive particularly strong protection.

Think:

PRIVILEGE
   ↑
AUTHENTICATION STRENGTH
   ↑

Finding Example

Finding:
Privileged Identity Without Required MFA

Observation:
An administrative account can authenticate
without the organization's required
multi-factor authentication control.

Risk:
Compromise of a single credential may lead
directly to privileged access.

Recommendation:
Require approved strong authentication for
all privileged identities and monitor
policy exceptions.

Part 12 — Authentication Method Governance

Review:

Registered Methods

Old Methods

Unused Methods

Recovery Methods

Helpdesk Reset Procedures

Security Lesson

Strong authentication can be undermined by:

Weak Recovery

Example:

Strong MFA
      ↓
Weak Account Reset Process
      ↓
Attacker Recovers Account

Part 13 — Passwordless Authentication

Where your environment supports it, understand passwordless options conceptually.

The security objective is to reduce:

Reusable Password Exposure

A high-level flow is:

USER
  ↓
STRONG AUTHENTICATOR
  ↓
CRYPTOGRAPHIC VERIFICATION
  ↓
ACCESS

Part 14 — Review Conditional Access

Conditional Access is a major identity-security control.

Review policies through approved administrative tools.

For each policy record:

Policy Name

Enabled State

Target Users

Target Applications

Conditions

Grant Controls

Exclusions

Conditional Access Mental Model

ACCESS REQUEST
      ↓
WHO?
      ↓
FROM WHAT DEVICE?
      ↓
TO WHICH APP?
      ↓
WHAT RISK?
      ↓
APPLY POLICY
      ↓
ALLOW / REQUIRE CONTROL / BLOCK

Part 15 — Review Policy Coverage

Ask:

Are Administrators Covered?

Are Sensitive Applications Covered?

Are Legacy Paths Addressed?

Are Risk-Based Controls Used Where Appropriate?

Are Exclusions Documented?

Part 16 — Review Exclusions

Policy exclusions deserve special attention.

An exclusion may be legitimate for:

Emergency Access

Service Dependency

Migration

Testing

but it should have:

Owner

Reason

Approval

Review Date

Finding Example

Finding:
Uncontrolled Conditional Access Exclusion

Observation:
A user or group is excluded from a
security policy without a documented
business reason or review date.

Risk:
The excluded identity may bypass controls
required for the broader user population.

Recommendation:
Validate the exclusion, document business
ownership, and remove it if no longer
required.

Part 17 — Emergency Access Review

Identify emergency-access identities if the organization uses them.

Verify:

Known Owner

Strong Protection

Very Limited Use

Monitoring

Documented Procedure

Regular Validation

Security Principle

Emergency access should not become:

Convenient Daily Administrator Account

Part 18 — Review Administrative Roles

List administrative roles and members using the approved tenant-management interface.

Focus on:

Highly Privileged Roles

Security Roles

Identity Roles

Application Roles

Device Roles

Privileged Role Matrix

Create:

Role	Member	Required	Permanent	Review
High Privilege Role	Admin-A	Yes	Review	Current
User Admin Role	Admin-B	Yes	Review	Current
Security Role	Analyst-A	Yes	Review	Current

Part 19 — Apply Least Privilege

Ask for every role:

Does the User Need This Role?

Could a Smaller Role Work?

Does Access Need to Be Permanent?

Can It Be Time-Limited?

When Was It Last Reviewed?

Finding Example

Finding:
Excessive Administrative Role Assignment

Observation:
An identity holds a broad administrative
role beyond the permissions required for
its documented job function.

Risk:
Identity compromise or misuse may provide
unnecessary control over enterprise
resources.

Recommendation:
Replace the broad role with the minimum
administrative role required for the
approved task.

Part 20 — Standing Privilege

Standing privilege means an identity is privileged continuously.

Example:

Admin User
     ↓
Permanent High-Level Role

The problem is:

Account Compromised
      ↓
Privilege Immediately Available

Better Model

Where appropriate:

ELIGIBLE
  ↓
ACTIVATE
  ↓
JUSTIFY
  ↓
TIME-LIMITED ACCESS
  ↓
EXPIRE

Part 21 — Privileged Identity Management

Review whether privileged access is controlled using mechanisms such as:

Eligibility

Activation

Approval

MFA

Time Limits

Audit

Access Reviews

depending on available capabilities.

PIM Security Model

USER
  ↓
ELIGIBLE ROLE
  ↓
ADMIN TASK
  ↓
ACTIVATE
  ↓
SECURITY REQUIREMENTS
  ↓
TEMPORARY PRIVILEGE
  ↓
EXPIRE

Part 22 — Review Access Reviews

Access reviews help answer:

Does This Identity
Still Need This Access?

Review processes for:

Privileged Roles

Groups

Guests

Enterprise Applications

Access Review Workflow

ACCESS EXISTS
      ↓
OWNER REVIEWS
      ↓
KEEP / CHANGE / REMOVE
      ↓
DOCUMENT RESULT

Part 23 — Review Guest Users

Guest identities often support:

Partners

Consultants

Vendors

External Project Teams

Review all guest accounts.

Capture:

Guest Name

Sponsor

Resource

Created Date

Last Activity

Business Expiration

Guest Security Questions

Ask:

Who Invited Them?

Who Sponsors Them?

What Can They Access?

When Should Access End?

Is Their Access Reviewed?

Part 24 — Identify Stale Guests

Potential stale guest indicators include:

No Current Sponsor

Project Completed

No Expected Recent Activity

No Known Resource Requirement

Finding Example

Finding:
Stale External Guest Identity

Observation:
An external guest retains access after the
documented project or business engagement
has ended.

Risk:
External access may remain available
without current business authorization.

Recommendation:
Validate sponsorship and remove guest
access if the external relationship is no
longer active.

Part 25 — Review Enterprise Applications

Enterprise applications may provide users access to SaaS or internal services.

For each application review:

Application Name

Owner

Business Purpose

User Assignment

Authentication Model

Permissions

Last Review

Enterprise Application Model

USER
  ↓
Microsoft Entra ID
  ↓
ENTERPRISE APPLICATION
  ↓
BUSINESS RESOURCE

Part 26 — Review Application Assignments

Ask:

Who Can Access the Application?

Is Assignment Required?

Are Groups Used?

Are Guests Included?

Does Everyone Need Access?

Part 27 — Review Application Permissions

Applications may have significant access.

Review:

Requested Permissions

Approved Permissions

Administrative Consent

Business Requirement

Data Access

Security Principle

Treat application permissions like user privilege.

Ask:

What Is the Minimum
This Application Needs?

Part 28 — Review Application Owners

Applications should have:

Technical Owner

Business Owner

Security Contact

An application with no known owner creates lifecycle risk.

Part 29 — Workload Identities

Cloud workloads may authenticate without human users.

Examples include:

Applications

Automation

Services

Managed Identities

Service Principals

Workload Identity Mental Model

APPLICATION
   ↓
WORKLOAD IDENTITY
   ↓
PERMISSION
   ↓
RESOURCE

Part 30 — Review Workload Identity Security

For every workload identity ask:

Who Owns It?

What Uses It?

What Can It Access?

How Does It Authenticate?

Are Credentials Long-Lived?

Is It Monitored?

Is It Still Needed?

Part 31 — Review Secrets and Certificates

Where applications use secrets or certificates, review:

Credential Type

Expiration

Owner

Rotation

Storage

Business Dependency

Security Principle

Avoid:

Long-Lived Secret
      +
High Privilege
      +
No Owner

This creates a high-risk identity.

Part 32 — Managed Identity Concept

Where supported, managed identities can reduce manually managed secrets.

Conceptually:

WORKLOAD
   ↓
MANAGED IDENTITY
   ↓
RESOURCE PERMISSION

Important

Managed identity reduces credential-management burden.

It does not remove the need for:

Least Privilege

Part 33 — Review Sign-In Logs

Sign-in logs help answer:

Who Signed In?

When?

From Where?

To Which Application?

From Which Device?

Was Authentication Successful?

Which Policies Applied?

Sign-In Investigation Model

USER
 ↓
TIME
 ↓
SOURCE
 ↓
DEVICE
 ↓
APPLICATION
 ↓
AUTHENTICATION
 ↓
POLICY
 ↓
RESULT

Part 34 — Establish Normal Sign-In Patterns

Before declaring activity suspicious, understand:

Normal User Location

Normal Device

Normal Applications

Normal Working Hours

Normal Authentication Method

Security Lesson

An unfamiliar sign-in is:

Something to Investigate

not automatically:

Proof of Compromise

Part 35 — Review Failed Sign-Ins

Look for patterns such as:

Repeated Failures

Multiple Locations

Multiple Applications

Unexpected Legacy Authentication

Privileged Account Failures

Investigation Questions

Was the User Traveling?

Was the Password Recently Changed?

Is an Old Device Using Stored Credentials?

Is This Normal Application Behavior?

Is There Evidence of Credential Guessing?

Part 36 — Review Successful Sign-Ins

Successful access deserves attention too.

Particularly review:

Privileged Users

Unusual Locations

Unmanaged Devices

Unexpected Applications

High-Risk Sessions

Part 37 — Review Authentication Details

Where available, assess:

Authentication Requirement

Authentication Method

MFA Result

Device State

Conditional Access Result

This can help distinguish:

Password-Only Access

from:

Strongly Verified Access

Part 38 — Review Audit Logs

Audit activity helps answer:

Who Changed What?

Review sensitive changes such as:

New User

New Administrator

Group Membership Change

Conditional Access Change

Application Change

Authentication Method Change

Audit Investigation Model

CHANGE
  ↓
ACTOR
  ↓
TIME
  ↓
TARGET
  ↓
OLD STATE
  ↓
NEW STATE

Part 39 — Privilege Change Investigation

Scenario:

User Added to
Highly Privileged Role

Investigate:

Who Added Them?

When?

Why?

Was It Approved?

Was It Permanent?

What Did the User Do Afterwards?

Part 40 — New Authentication Method Scenario

Scenario:

New Authentication Method
Registered for Administrator

Ask:

Was the Administrator Expecting It?

Who Registered It?

Was Strong Verification Performed?

Were Other Suspicious Events Present?

Part 41 — Identity Risk Concepts

Identity risk features can help highlight:

Potentially Compromised Users

Suspicious Sign-Ins

Unusual Authentication

depending on environment and licensing.

Risk Assessment Principle

Risk signal:

≠
Confirmed Compromise

Use risk as:

Investigation Priority

Part 42 — Risky Sign-In Review

For a risky sign-in review:

Identity

Source

Device

Application

Authentication

Conditional Access

Subsequent Activity

Part 43 — Risky User Review

A risky user may warrant broader investigation.

Review:

Recent Sign-Ins

Password Events

Authentication Methods

Privileged Roles

Applications

Mailbox Activity

Device Activity

where authorized and relevant.

Part 44 — Identity Compromise Scenario

Scenario:

Phishing
   ↓
Password Stolen
   ↓
Suspicious Sign-In
   ↓
Cloud Application Access

Your investigation should follow:

IDENTITY
  ↓
SIGN-IN
  ↓
DEVICE
  ↓
AUTHENTICATION
  ↓
SESSION
  ↓
APPLICATION
  ↓
ACTIVITY

Part 45 — Identity Incident Response

If compromise is confirmed, an approved response process may involve:

Restrict Account

Revoke Sessions

Reset Credentials

Review Authentication Methods

Remove Unauthorized Privilege

Review Application Access

Review Mailbox / Data Activity

Increase Monitoring

Important

Identity response should not stop at:

Password Reset

because active sessions, application access, or changed authentication methods may still matter.

Part 46 — Review Session Risk

Cloud access often relies on sessions after authentication.

Therefore:

Credential Reset

and:

Session Revocation

are separate security considerations.

Part 47 — Conditional Access Scenario

Scenario:

Privileged User
Attempts Access
from Unmanaged Device

Design goal:

IDENTITY
  +
DEVICE
  +
APPLICATION
  +
RISK
      ↓
ACCESS DECISION

Depending on policy:

Require Strong Control

or:

Restrict Access

Part 48 — Guest Scenario

Scenario:

Consultant Project Ended
45 Days Ago

Guest Access Remains

Recommended workflow:

Confirm Project Status
      ↓
Validate Sponsor
      ↓
Review Current Access
      ↓
Remove Unnecessary Access
      ↓
Document Closure

Part 49 — Excessive Admin Scenario

Scenario:

Helpdesk User
Has Broad Tenant-Wide Admin Role

Ask:

Which Actual Tasks
Does the User Perform?

Then map:

TASK
  ↓
MINIMUM ROLE

Part 50 — Application Permission Scenario

Scenario:

Reporting Application
Only Reads Basic Data

but possesses:

Broad Administrative Permission

Review:

Required Function

Current Permission

Minimum Permission

Business Owner

Impact of Reduction

Part 51 — Build an Identity Inventory

Create:

Identity	Type	Enabled	Privileged	Owner	Status
Alice	Employee	Yes	No	Manager-A	Active
Admin-Bob	Admin	Yes	Yes	IT	Review
Vendor-1	Guest	Yes	No	Project-A	Review
App-01	Workload	Yes	Review	App Team	Active

Part 52 — Build an MFA Matrix

Identity Group	MFA Required	Current State	Finding
Administrators	Yes	Review
Employees	Yes/Policy	Review
Guests	Policy Based	Review
Emergency Access	Special Design	Review

Part 53 — Build a Conditional Access Matrix

Policy	Users	Applications	Control	Exclusions
Admin Security	Admins	Admin Apps	Strong Authentication	Review
Sensitive Apps	Selected Users	Critical Apps	Compliant Device	Review
Risk Policy	Scoped Users	Cloud Apps	Risk Control	Review

Part 54 — Build a Privileged Role Matrix

Identity	Role	Required	Permanent	Owner
Admin-A	High Privilege	Yes	Review	IT
Admin-B	User Admin	Yes	Review	IAM
User-C	High Privilege	No	Yes	Review

Part 55 — Build a Guest Access Matrix

Guest	Sponsor	Resource	Last Review	Action
Vendor-A	Manager-A	Project Site	Current	Keep
Vendor-B	Unknown	Legacy App	Old	Review

Part 56 — Build an Application Identity Matrix

Application	Owner	Identity Type	Privilege	Credential
App-A	App Team	Service Principal	Limited	Certificate
App-B	Unknown	Service Principal	Broad	Secret
Workload-C	Cloud Team	Managed Identity	Limited	Managed

Part 57 — Identity Baseline

Define expected controls:

Control	Expected State
Privileged MFA	Required
Dormant Users	Disabled/Reviewed
Privileged Roles	Least Privilege
Guest Access	Sponsored and Reviewed
Conditional Access	Documented
Application Access	Least Privilege
Sign-In Logging	Enabled
Audit Logging	Enabled

Part 58 — Compare Baseline to Reality

Example:

Control	Expected	Actual	Result
Admin MFA	Required	Missing for 1 account	Fail
Guest Review	Current	Several stale	Fail
Privilege	Minimum	Excessive assignment	Fail
Sign-In Logs	Available	Available	Pass
App Ownership	Required	Unknown owner	Fail

Part 59 — Prioritize Identity Risk

Consider:

Privilege

Authentication Strength

Exposure

Resource Sensitivity

Activity

Credential Type

Business Impact

High-Risk Combination

Privileged Account
      +
Weak Authentication
      +
No Conditional Access
      +
No Monitoring

should receive higher priority.

Part 60 — Finding: Weak Privileged Authentication

Finding:
Weak Authentication on Privileged Identity

Observation:
A privileged account does not meet the
organization's required strong
authentication standard.

Risk:
Credential compromise may lead directly to
administrative access.

Recommendation:
Apply the approved privileged
authentication standard and validate
policy enforcement.

Part 61 — Finding: Standing Privilege

Finding:
Unnecessary Standing Administrative Access

Observation:
A user retains permanent privileged access
despite performing administrative tasks
only occasionally.

Risk:
The privileged permissions remain
continuously available if the identity is
compromised.

Recommendation:
Use eligible or time-limited administrative
access where appropriate and review
privileged assignments regularly.

Part 62 — Finding: Stale Guest Account

Finding:
Stale Guest Access

Observation:
An external identity remains enabled after
the associated business engagement has
ended.

Risk:
External access may remain available
without current authorization.

Recommendation:
Remove unnecessary guest access and
establish recurring sponsor-based reviews.

Part 63 — Finding: Conditional Access Gap

Finding:
Sensitive Application Not Protected by
Required Access Policy

Observation:
A sensitive enterprise application can be
accessed without the organization's
expected device or authentication controls.

Risk:
Compromised credentials may provide access
without additional contextual validation.

Recommendation:
Apply an approved Conditional Access policy
aligned with the application's risk and
business requirements.

Part 64 — Finding: Excessive Application Permission

Finding:
Over-Privileged Application Identity

Observation:
An application identity possesses
permissions beyond those required for its
documented function.

Risk:
Compromise of the workload identity could
provide unnecessary access to enterprise
data or services.

Recommendation:
Reduce permissions to the minimum required
scope and implement recurring application
access reviews.

Part 65 — Finding: Unknown Application Owner

Finding:
Application Identity Without Defined Owner

Observation:
An enterprise application or workload
identity has no documented accountable
owner.

Risk:
Security permissions, credentials, and
business need may not be reviewed
throughout the application's lifecycle.

Recommendation:
Assign technical and business ownership and
establish periodic identity and permission
review.

Part 66 — Identity Security Report

Your final report should include the following.

1. Executive Summary

Document:

Tenant Assessed

Overall Identity Posture

Critical Identity Risks

Highest-Priority Recommendations

2. Identity Population

Include:

Employees

Administrators

Guests

Workload Identities

Disabled Accounts

3. Authentication

Document:

MFA Coverage

Authentication Methods

Passwordless Adoption

Recovery Controls

Observed Weaknesses

4. Conditional Access

Document:

Policies

Scope

Target Applications

Controls

Exclusions

Observed Gaps

5. Privileged Access

Document:

Administrative Roles

Permanent Privilege

Eligible Privilege

Access Reviews

Emergency Access

6. Guest Access

Document:

Guest Population

Sponsors

Stale Guests

Application / Resource Access

Review Process

7. Applications

Document:

Enterprise Applications

Owners

Permissions

Assignments

Workload Identities

Credentials

8. Monitoring

Document:

Sign-In Logs

Failed Authentication

Risk Events

Audit Logs

Privileged Changes

9. Findings

For each finding include:

ID

Title

Severity

Observation

Evidence

Risk

Recommendation

Owner

Target Date

Part 67 — Identity Security Checklist

Scope

• Defined tenant
• Defined user population
• Identified critical applications
• Identified privileged identities
• Defined assessment period

Users

• Reviewed enabled users
• Reviewed disabled users
• Reviewed dormant users
• Reviewed account ownership
• Reviewed lifecycle

Groups

• Reviewed important groups
• Reviewed group owners
• Reviewed group membership
• Identified privilege creep
• Reviewed stale access

Authentication

• Reviewed authentication methods
• Reviewed MFA
• Reviewed privileged authentication
• Reviewed account recovery
• Understood passwordless concepts

Conditional Access

• Reviewed policies
• Reviewed user scope
• Reviewed application scope
• Reviewed conditions
• Reviewed exclusions
• Reviewed emergency access

Privileged Access

• Reviewed admin roles
• Identified standing privilege
• Reviewed least privilege
• Reviewed privileged lifecycle
• Reviewed access reviews

Guests

• Reviewed guest inventory
• Identified sponsors
• Identified stale guests
• Reviewed access
• Reviewed expiration

Applications

• Reviewed enterprise applications
• Reviewed owners
• Reviewed assignments
• Reviewed permissions
• Reviewed workload identities
• Reviewed credentials

Monitoring

• Reviewed sign-in logs
• Reviewed failed sign-ins
• Reviewed successful sign-ins
• Reviewed audit activity
• Reviewed privileged changes
• Understood identity risk

Reporting

• Created identity inventory
• Created MFA matrix
• Created Conditional Access matrix
• Created privileged-role matrix
• Created guest-access matrix
• Created workload-identity matrix
• Documented findings
• Produced final report

Common Identity Security Mistakes

Avoid:

Relying Only on Passwords

Ignoring Guest Accounts

Giving Broad Administrator Roles

Leaving Privilege Permanent

Creating Undocumented Policy Exclusions

Ignoring Workload Identities

Using Long-Lived Application Secrets

Ignoring Sign-In Logs

Ignoring Authentication Method Changes

Keeping Dormant Accounts Enabled

Assuming MFA Solves Every Identity Threat

Identity Security Maturity Model

Level 1 — Basic

Users

Passwords

Groups

Basic Administration

Level 2 — Controlled

MFA

Least Privilege

Conditional Access

Guest Governance

Level 3 — Managed

Privileged Access Management

Access Reviews

Application Governance

Risk Detection

Central Monitoring

Level 4 — Zero Trust Identity

Strong Authentication

Device Context

Risk Context

Time-Limited Privilege

Continuous Review

Workload Identity Governance

Career Connection

This lab directly supports:

Identity Administrator

IAM Engineer

Identity Security Engineer

Microsoft Security Engineer

SOC Analyst

Cloud Security Engineer

Security Consultant

Security Architect

Interview Scenario 01

Why is identity considered a modern security perimeter?

Because enterprise resources can be accessed from many locations and devices, making identity and access context more important than simply trusting the corporate network.

Interview Scenario 02

What is the difference between MFA and Conditional Access?

MFA
=
Authentication Control

Conditional Access
=
Context-Based Access Decision

that may require MFA.

Interview Scenario 03

Why is permanent privilege risky?

Because the privilege is continuously available if the identity becomes compromised.

Interview Scenario 04

Why are guest accounts important in an identity assessment?

Because external identities may retain access beyond the original business relationship if sponsorship and lifecycle controls are weak.

Interview Scenario 05

Why must application identities follow least privilege?

Because compromised workload identities can access resources using their assigned permissions just like compromised human identities.

40 Identity Security Interview Questions

1. What is Microsoft Entra ID?
2. What is an identity tenant?
3. What is identity security?
4. Why is identity considered a security perimeter?
5. What is authentication?
6. What is authorization?
7. What is MFA?
8. Why is MFA important?
9. Is MFA enough to prevent all identity attacks?
10. What is passwordless authentication?
11. What is Conditional Access?
12. Which signals can Conditional Access evaluate?
13. What is least privilege?
14. What is RBAC?
15. What is a privileged identity?
16. What is standing privilege?
17. What is just-in-time access?
18. What is Privileged Identity Management?
19. Why are access reviews important?
20. What is privilege creep?
21. What is a guest identity?
22. Why should guest accounts have sponsors?
23. What is an enterprise application?
24. What is application assignment?
25. What is a service principal?
26. What is a workload identity?
27. What is a managed identity?
28. Why are long-lived application secrets risky?
29. What should be reviewed in sign-in logs?
30. What is a failed sign-in?
31. What is a risky sign-in?
32. What is user risk?
33. What information appears in audit activity?
34. Why should authentication-method changes be monitored?
35. What is an emergency-access account?
36. How would you review administrator access?
37. How would you investigate a suspicious sign-in?
38. How would you review guest access?
39. How would you assess an application identity?
40. How would you perform a Microsoft identity-security assessment?

Final Identity Security Mental Model

When assessing identity, ask:

WHO EXISTS?
    ↓
WHO CAN AUTHENTICATE?
    ↓
HOW STRONG IS AUTHENTICATION?
    ↓
WHICH GROUPS?
    ↓
WHICH ROLES?
    ↓
WHO IS PRIVILEGED?
    ↓
WHICH POLICIES APPLY?
    ↓
WHICH APPLICATIONS HAVE ACCESS?
    ↓
WHICH GUESTS EXIST?
    ↓
WHAT DO THE LOGS SHOW?
    ↓
IS ACCESS STILL REQUIRED?

Mission Accomplished

You have now assessed Microsoft identity security across:

Users

Groups

Authentication

MFA

Conditional Access

Administrative Roles

Privileged Access

Guest Identities

Enterprise Applications

Workload Identities

Sign-In Activity

Audit Activity

Identity Risk

The key lesson is:

Identity Security
Is Not Just Authentication

It is the continuous control of:

WHO
  +
HOW
  +
WHAT
  +
WHEN
  +
FROM WHERE
  +
WITH WHICH PRIVILEGE

What’s Next?

➡️ Lab 04 — Microsoft 365 Security

In the next lab, you will move from identity security into the wider Microsoft 365 tenant.

You will assess:

Microsoft 365 Tenant
      ↓
Administrative Access
      ↓
Exchange Online
      ↓
Email Security
      ↓
Teams
      ↓
SharePoint
      ↓
OneDrive
      ↓
External Sharing
      ↓
Data Protection
      ↓
Audit
      ↓
Security Alerts
      ↓
Tenant Security Findings

Your Microsoft lab sequence continues:

Lab 01 — Active Directory
        ↓
Lab 02 — Endpoint Security
        ↓
Lab 03 — Identity Security
        ↓
Lab 04 — Microsoft 365 Security
        ↓
Lab 05 — Windows Security
        ↓
Runbook 01 — Active Directory Assessment
        ↓
Runbook 02 — Microsoft 365 Security Review
        ↓
Runbook 03 — Windows Security Assessment