Scenario
Engineering teams supporting applications across development, test, staging, and production environments face a persistent tension: operational visibility requires broad read access, while security mandates strict control over write operations. Standing Contributor or Owner access increases the blast radius of credential compromise and violates least-privilege principles. Conversely, removing all write access impedes agility, forcing engineers to request temporary access through informal channels that lack auditability.
This article outlines an architecture where engineering team members retain permanent Reader access for operational visibility. Write access is granted as eligible assignments via Microsoft Entra Privileged Identity Management (PIM). Activation requires multifactor authentication (MFA), a change-ticket reference, business justification, and approval from a designated group. The activation window is risk-based, shorter for production, and enforced by Conditional Access policies.
Target Architecture
The architecture relies on separating standing access from privileged elevation. Engineers are assigned the Reader role permanently at the subscription or resource group scope to ensure they can monitor resource health, view configurations, and troubleshoot without modifying state. Write permissions are never standing; they are eligible assignments configured in PIM.
Role settings in PIM define the governance rules. These settings are independent per role and per resource, meaning a policy configured at the subscription level does not automatically inherit to resource groups. Therefore, policies must be explicitly configured for each scope where elevation is permitted. The design avoids broad Contributor or Owner assignments where narrower built-in roles (e.g., Virtual Machine Contributor, Storage Account Contributor) or custom roles can satisfy the specific task. This reduces the potential impact of a compromised session.
Request and Approval Flow
The flow begins when an engineer identifies a need to modify a resource. Because they hold only standing Reader access, they cannot perform write operations. They navigate to the Microsoft Entra admin center, select Identity Governance > Privileged Identity Management > My roles, and locate their eligible Azure resource role.
Upon selecting Activate, the system enforces the configured role settings:
- Authentication: MFA is required. To ensure strong verification, the architecture uses On activation, require Microsoft Entra Conditional Access authentication context. This redirects the user to satisfy Conditional Access policies, such as requiring a compliant device or a specific authentication strength, rather than relying solely on the default MFA prompt which might be satisfied by a previous session token.
- Justification and Ticketing: The user must enter a business justification and a support ticket number. Note that the ticket field is informational; PIM does not enforce correlation with an external ticketing system.
- Approval: If the role setting requires approval, the request enters a pending state. A designated approver group reviews the request. The approver does not need to hold any specific Azure role to approve.
- Scope Reduction: During activation, the user can further scope the request. For example, if eligible at the subscription level, they can select a specific resource group or resource, ensuring the active assignment is as narrow as possible.
Once approved and authenticated, PIM creates an active assignment within seconds. The user can now perform write operations. When the activation duration expires, or if the user manually deactivates, PIM removes the active assignment within seconds. Applications may cache access tokens, so signing out and back in may be required to reflect the removal of permissions immediately.
Implementation Steps
Implementing this pattern requires configuring PIM role settings and Conditional Access policies.
- Assign Eligible Roles: Assign engineers eligible roles in PIM for the target subscriptions or resource groups. Do not assign permanent active roles for write access.
- Configure Role Settings: In the Microsoft Entra admin center, navigate to ID Governance > Privileged Identity Management > Azure resources. Select the resource and the role, then edit settings. Set the Activation maximum duration. For development and test, an organization may configure up to 8 hours. For staging and production, configure shorter durations based on risk assessment. Enable Require multifactor authentication and Require justification and Require ticket information. Enable Require approval to activate and select the approver group.
- Configure Conditional Access: Create a Conditional Access policy targeting the authentication context defined in PIM. Ensure the policy enforces strong authentication methods (e.g., passwordless sign-in) and device compliance. Set the sign-in frequency to Every time under Session controls to force reauthentication on every activation. Note that if no Conditional Access policy targets the context, PIM falls back to standard MFA, but this is a backup mechanism, not a primary control.
- Deploy Secure Workstations: For staging and production, enforce access from protected administrative workstations or Intune-compliant devices via Conditional Access. This ensures the platform attests the identity and device health before granting elevation.
Audit and Evidence
Effective governance requires correlating access decisions with resource changes. Two distinct log sources are involved:
- PIM Audit History: Records eligibility, requests, approvals, activations, and expiry. It captures the who, when, and why of the privilege elevation. You can view this in the Microsoft Entra admin center under Resource audit or My audit. It includes the justification and ticket number entered by the user.
- Azure Activity Log: Records management operations (control plane) such as creating a virtual machine or changing a key vault policy. It captures the what was changed in the resource plane. The activity log does not typically capture read operations.
The monitoring design must correlate these records by identity, scope, and time. For example, if a user activated a role for 2 hours, the Activity Log should only show write operations from that user within that 2-hour window. Any write operation outside the activation window indicates a standing permission leak or a misconfigured role. Azure retains activity log events for 90 days by default; for longer retention, route logs to an Azure storage account via diagnostic settings.
Failure Modes and Trade-offs
Implementing just-in-time access introduces operational friction. Engineers must plan their work around activation windows. If an activation expires before a task is complete, a new request must be submitted, requiring re-approval and re-authentication. This can delay incident response if the approval chain is not available.
Another trade-off is the complexity of Conditional Access. If a Conditional Access policy targeting the PIM authentication context is misconfigured or disabled, PIM falls back to standard MFA. However, this backup mechanism is not triggered if the policy is in report-only mode or if the user is excluded. Administrators must ensure that security principals managing Conditional Access policies are highly privileged and protected.
Additionally, PIM role settings do not inherit. A policy set at the subscription level does not apply to resource groups. Administrators must configure settings at each scope where elevation is allowed, increasing configuration overhead.
Implementation Checklist
- Access Baseline: Verify all engineering team members have standing Reader access only.
- Eligible Assignments: Confirm write roles are assigned as eligible in PIM, not active.
- Role Settings: Ensure Activation maximum duration is set (e.g., <8 hours for prod). Enable MFA, justification, ticketing, and approval.
- Conditional Access: Deploy policies targeting the PIM authentication context with Every time sign-in frequency.
- Device Compliance: Enforce Intune-compliant devices or secure workstations for staging and production activations.
- Audit Correlation: Validate that PIM activation logs correlate with Azure Activity Log entries for write operations.
- Review: Conduct regular access reviews to remove eligible assignments for personnel who no longer need them.
Conclusion
Just-in-time access transforms privilege from a static state to a dynamic, auditable event. By combining standing Reader access with eligible PIM roles, organizations can maintain engineering agility while enforcing strict least-privilege controls. The key is rigorous configuration of role settings, Conditional Access policies, and audit correlation to ensure that every write operation is authorized, authenticated, and recorded.