How to Implement Just-in-Time Access for Privileged Accounts

Entra PIM is included in Azure AD P2 and Microsoft 365 E5/Business Premium plans. It implements JIT for Azure AD directory roles, Azure subscription roles, and Microsoft 365 roles.

Step 1: Identify current standing privileged assignments

# Install the Microsoft Graph module if not present
Install-Module Microsoft.Graph -Scope CurrentUser
Connect-MgGraph -Scopes "RoleManagement.Read.Directory"

# List all permanent Global Admin assignments (not JIT-eligible)
Get-MgRoleManagementDirectoryRoleAssignment |
    Where-Object { $_.AssignmentType -eq 'Assigned' } |
    Join-Object -MergeScript {
        Get-MgDirectoryRoleDefinition -UnifiedRoleDefinitionId $_.RoleDefinitionId
    } | Where-Object { $_.DisplayName -eq 'Global Administrator' } |
    Select-Object PrincipalId, DirectoryScopeId

Step 2: Convert standing assignments to eligible assignments

In the Entra portal (entra.microsoft.com):

1. Navigate to Identity Governance > Privileged Identity Management > Azure AD Roles
2. Select the role to configure (e.g., Global Administrator)
3. Under 'Assignments', find each permanent (Active) assignment
4. Click the assignment > Change type > Eligible
5. Set the eligible assignment duration (recommend 12 months, requiring annual renewal review)

The user now has no standing Global Admin access. When they need it, they activate it through PIM.

Step 3: Configure activation requirements

For each role under Settings:

• Activation maximum duration: 4-8 hours for standard admin tasks; 1 hour for highly privileged roles (Global Admin, Privileged Role Admin)
• Require justification: Yes: users must provide a business justification for each activation
• Require approval: Yes for highly privileged roles; optional for lower-risk roles (speeds up workflows for frequently-used access)
• Require MFA: Yes: always require MFA re-authentication at activation, even if MFA was already satisfied earlier in the session
• Require ticket information: Optional: useful in organizations with ITSM tools (require a ServiceNow ticket number)

Step 4: Test the activation workflow

As a user with an eligible assignment:

1. Navigate to entra.microsoft.com > My roles
2. Click 'Activate' next to the eligible role
3. Provide justification, complete MFA, wait for approval if required
4. Verify access is granted for the configured window
5. Verify the role appears in the Audit log with the justification text

AWS implements JIT through IAM role assumption with temporary credentials. Instead of assigning permanent Admin permissions to IAM users, users assume a privileged role for a temporary session.

Step 1: Create the privileged role

// Create an IAM role with an AdministratorAccess policy and a trust policy
// that allows specific IAM users to assume it
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": [
        "arn:aws:iam::123456789012:user/alice",
        "arn:aws:iam::123456789012:user/bob"
      ]
    },
    "Action": "sts:AssumeRole",
    "Condition": {
      "Bool": {
        "aws:MultiFactorAuthPresent": "true"  // Require MFA to assume the role
      },
      "NumericLessThan": {
        "aws:MultiFactorAuthAge": "3600"  // MFA must have been used within the last hour
      }
    }
  }]
}

Step 2: Grant users the permission to assume the role (only)

The IAM users themselves have minimal permissions: only the ability to assume the privileged role:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::123456789012:role/PlatformAdminRole"
  }]
}

Step 3: Assume the role to get temporary credentials

# Assume the admin role with a 1-hour session (3600 seconds)
# Note: max duration is 12 hours, configurable per role
aws sts assume-role \
    --role-arn "arn:aws:iam::123456789012:role/PlatformAdminRole" \
    --role-session-name "alice-maintenance-$(date +%Y%m%d%H%M%S)" \
    --duration-seconds 3600 \
    --serial-number arn:aws:iam::123456789012:mfa/alice \
    --token-code 123456  # MFA token code

The response contains temporary AccessKeyId, SecretAccessKey, and SessionToken valid for exactly 3600 seconds. When the session expires, the credentials stop working: no manual revocation required.

Step 4: Require session name to include justification

Configure your IAM policy to require that role session names follow a naming convention that includes a ticket number:

"Condition": {
  "StringLike": {
    "sts:RoleSessionName": "*-TICKET-*"  // Require ticket reference in session name
  }
}

Monitoring JIT access:

All JIT activations should be logged and monitored:

/* Splunk: Azure PIM activation audit */
index=azure_audit OperationName="Add eligible member to role in PIM completed"
| table TimeGenerated, UserPrincipalName, TargetRole, Justification, Duration
| sort -TimeGenerated

/* Alert: After-hours PIM activation (potential credential compromise) */
index=azure_audit OperationName="Add eligible member to role in PIM completed"
| eval hour = strftime(_time, "%H")
| where hour < 7 OR hour > 19  /* Outside normal business hours */
| table TimeGenerated, UserPrincipalName, TargetRole, Justification

Break-glass accounts:

JIT access requires the authentication system to be operational: if Entra PIM is unavailable, nobody can activate privileged roles. Every JIT implementation needs at least one break-glass account: a permanent Global Admin account (for Azure) or an IAM user with AdminstratorAccess (for AWS) that is:

• Stored in a sealed physical envelope in a secure location (not a password manager)
• Protected with MFA via a hardware key (not a software authenticator that requires a functional device)
• Monitored with an alert that fires any time the account is used
• Tested semi-annually to verify the credentials still work

The break-glass account is the last resort: its use should trigger immediate investigation of whether normal access paths are working and why the break-glass was needed.