PIM: Azure Resources, Groups & Audit
Extend PIM to Azure resource roles and group membership, audit PIM activity through logs and reports, and secure break-glass accounts for emergency access.
PIM Beyond Entra Roles
PIM isn’t just for Entra admin roles — it protects Azure subscriptions and group memberships too.
Think of it this way: in the previous module, we put the admin office keys in a safe (PIM for Entra roles). Now we’re also putting the server room keys (Azure resource roles) and the team badge access (group memberships) in the same safe system.
And we’re setting up security cameras (audit logs) to record who opened the safe, when, and why. Plus, we’re hiding one emergency key under a rock for absolute emergencies (break-glass accounts) — but even that has rules.
PIM for Azure resources
PIM for Azure resources works just like PIM for Entra roles, but targets Azure RBAC roles at any scope:
| Scope Level | Example | PIM Use Case |
|---|---|---|
| Management group | Company-wide policies | Eligible Owner for top-level governance |
| Subscription | Production subscription | Eligible Contributor for deployments |
| Resource group | ”rg-clinical-apps” | Eligible Reader for monitoring |
| Individual resource | A specific VM or storage account | Eligible role for that resource only |
Key differences from PIM for Entra roles:
| Feature | PIM for Entra Roles | PIM for Azure Resources | PIM for Groups |
|---|---|---|---|
| What it manages | Entra directory roles (Global Admin, User Admin, etc.) | Azure RBAC roles (Owner, Contributor, Reader, custom) | Group membership or ownership |
| Scope | Tenant-wide | Management group, subscription, resource group, or resource | The group itself |
| Activation portal | Entra admin center → PIM | Entra admin center → PIM → Azure resources | Entra admin center → PIM → Groups |
| Licensing | Entra ID P2 or Entra ID Governance | Entra ID P2 or Entra ID Governance | Entra ID P2 or Entra ID Governance |
| Settings | Per Entra role | Per Azure role at each scope | Per group |
| Use case | Admin role governance | Azure infrastructure access governance | Indirect access to anything the group grants |
Scenario: Priya extends PIM to Azure subscription roles
🔐 Priya configures PIM for Meridian Health’s production Azure subscription:
Owner role PIM settings:
- Maximum activation: 1 hour (Owner is extremely powerful)
- Require MFA: Yes
- Require approval: Yes — approved by the Cloud Governance team
- Require justification: Yes
Contributor role PIM settings:
- Maximum activation: 4 hours
- Require MFA: Yes
- Require approval: No (Contributor is less risky)
- Require justification: Yes
Eligible assignments:
- Ravi Patel → Eligible Contributor on the production subscription (activates when deploying)
- Priya → Eligible Owner (activates for governance changes only)
Now Ravi can deploy to production by activating Contributor for 4 hours, without having standing write access to the production environment.
PIM for Groups
PIM for Groups is powerful because it provides indirect just-in-time access to anything the group controls.
How it works:
- You enable a group for PIM (the group must be role-assignable or a security group)
- Users get eligible membership or eligible ownership of the group
- When they activate, they become a member/owner for the configured duration
- The group’s permissions (app assignments, Entra roles, Azure RBAC, SharePoint access) all activate with it
Why this matters: Instead of configuring PIM for each individual role, you can assign multiple roles to a group and manage PIM for the group. One activation grants everything the group provides.
Scenario: PIM for the Security Operations group
🔐 Priya creates a role-assignable security group called “Security Operations Active” that has:
- Security Reader Entra role
- Security Operator Entra role
- Reader role on the Security resource group in Azure
She enables PIM for this group and makes Anika an eligible member.
When Anika needs to investigate a security incident:
- Activates membership in “Security Operations Active” (justification + MFA)
- Immediately gets Security Reader + Security Operator + Azure Reader
- Investigates the incident
- Membership deactivates after the configured duration
One activation, three roles. Much simpler than activating three roles individually.
Exam tip: Role-assignable groups
Only role-assignable groups can be assigned Entra directory roles. If you want PIM for Groups to provide just-in-time access to Entra roles, the group must be created as role-assignable (this is set at creation time and cannot be changed later).
For Azure RBAC roles and app assignments, any security group works — role-assignable isn’t required for those scenarios.
PIM audit history and reports
PIM provides comprehensive auditing — every action is logged:
Audit sources:
| Log Type | What It Captures |
|---|---|
| PIM audit log | Role assignments, activations, deactivations, approvals, denials, setting changes |
| Entra audit log | All directory changes including PIM-related ones |
| Sign-in logs | When activated users sign in during their elevated session |
How to access PIM audit data:
- Entra admin center → PIM → Audit — filtered view of PIM events
- Entra admin center → PIM → [Role] → Audit — audit for a specific role
- Identity Governance → Access reviews — review history for PIM-triggered reviews
- Export to Log Analytics — for long-term retention and KQL queries (covered in next module)
Scenario: Anika audits PIM activations for a client
🛡️ Anika needs to produce a quarterly PIM report for Meridian Health’s compliance team:
- Opens PIM → Entra roles → Audit and filters to the last 90 days
- Reviews Global Admin activations: who activated, when, justification, duration
- Checks for anomalies: activations outside business hours, unusually long durations, multiple activations in short periods
- Downloads the audit log as CSV for the compliance report
- Reviews PIM alerts: no “Too many Global Admins” alerts, one “Role activated outside of PIM” alert → investigates the direct assignment
She also checks PIM → Azure resources → Audit for Azure role activations and verifies that no production Owner activations exceeded 1 hour.
Break-glass accounts
Break-glass accounts (also called emergency access accounts) are a critical safety net. If PIM, MFA, or your identity provider fails, you need a way to regain access.
What is a break-glass account? A cloud-only Global Administrator account that bypasses your normal security controls — specifically designed for emergencies.
How to set up break-glass accounts correctly:
| Requirement | Details |
|---|---|
| Number | At least 2 (redundancy) |
| Type | Cloud-only (not federated — must work if federation fails) |
| MFA | Require phishing-resistant MFA (FIDO2 key or CBA) via a dedicated CA policy. Store the FIDO2 key in a physical safe. |
| Conditional Access | Exclude from restrictive CA policies (location blocks, device compliance). Create a dedicated CA policy requiring phishing-resistant MFA for these accounts. |
| PIM assignment | Active permanent Global Admin — NOT eligible (can’t activate through PIM in an emergency when PIM itself might be down) |
| Password | Long, complex, not known to any single person (split between two people or stored in a physical safe) |
| Monitoring | Create an alert that fires whenever the account signs in |
| Testing | Test at least every 90 days to verify the account works |
| No regular use | Never used for daily tasks — only true emergencies |
Scenario: Priya secures Meridian Health's break-glass accounts
🔐 Priya creates two break-glass accounts for Meridian Health:
Account 1: emergency-admin-01@meridianhealth.onmicrosoft.com
- Cloud-only (uses the .onmicrosoft.com domain, not the federated custom domain)
- Active permanent Global Admin in PIM
- MFA: FIDO2 security key stored in the IT manager’s locked drawer
- Password: 24-character random string, first half known by Priya, second half known by the CTO
- Excluded from all Conditional Access policies
Account 2: emergency-admin-02@meridianhealth.onmicrosoft.com
- Same setup but with a different FIDO2 key stored in a different physical location
- Password halves known by different people than Account 1
Monitoring: Priya creates an alert rule in Azure Monitor that triggers whenever either account signs in → emails the security team immediately.
Testing: Every 90 days, Priya and the CTO assemble the password, sign in with the break-glass account, verify it works, change the password, and log the test.
Exam tip: Break-glass account common questions
The exam frequently tests break-glass account best practices:
- Must be cloud-only — if your on-premises AD or federation service fails, these accounts still work
- Exclude from Conditional Access — if a CA policy accidentally locks everyone out, break-glass accounts can fix it
- Active (not eligible) in PIM — you can’t activate through PIM if PIM itself is the problem
- At least two accounts — redundancy in case one is compromised or inaccessible
- Monitor sign-ins — any use should trigger an alert because these accounts should never be used in normal operations
Video Lesson
🎬 Video coming soon
PIM: Azure Resources, Groups & Audit
PIM: Azure Resources, Groups & Audit
~11 minKey Concepts
Knowledge Check
Ravi needs just-in-time Contributor access to the production Azure subscription for deployments. Currently he has permanent Contributor. What should Priya configure?
Priya is creating break-glass accounts. Which combination of settings is correct?
Anika wants to simplify PIM activation for security analysts who need Security Reader, Security Operator, and Azure Reader roles simultaneously. Currently they must activate each role separately. What should she recommend?
Next up: Identity Monitoring: Logs, KQL & Secure Score — how to monitor identity events with logs, write KQL queries for investigation, and improve your security posture with Identity Secure Score.