Chapter 10 — Access as Code, and the Evidence It Produces

How the program holds Conditional Access, PIM settings, groups, access packages and access reviews as versioned code, applies them through change control, detects drift, and maps the resulting records to NIST SP 800-53 AC-2, AC-3, AC-6, IA-2 and CA-7.

Chapter 10 — Access as Code, and the Evidence It Produces

An access policy that exists only as portal clicks can’t be diffed, reviewed, or replayed, so it can’t be assessed; held as code, every access decision has a source, a history, and an approver.

NoteIn this chapter

Which access objects the program keeps in a repository, and the tools that apply them (Microsoft Graph, the Terraform azuread provider, Microsoft365DSC, and Microsoft Entra Tenant Governance configuration management), with each tool’s status as of October 2026. Then the change-control rules that make the repository the only normal path to production, how drift is detected and closed, and the evidence an assessor reads, mapped to NIST SP 800-53 AC-2, AC-3, AC-6, IA-2 and CA-7.

The earlier chapters decided what the access policies are: the Conditional Access library (Chapter 07), PIM role settings (Chapter 08 and Appendix B), and the governance machinery (Chapter 09). This chapter is about how those decisions are held. A Conditional Access estate that nobody can diff is a control that no assessor can trace: IA-2 and AC-6 become assertions, and drift stays invisible until it becomes a finding.

The invariant this chapter enforces is that every access decision has a reviewable source of truth, that a pipeline applies that source, and that a monitor checks the tenant against it. Three consequences follow. A change is a pull request with an author and a reviewer, not an edit someone remembers making. The tenant can be compared with intent at any time. And the evidence (who approved what, when it was deployed, whether it is still true) is produced by doing the work, not reconstructed for the assessment.

Figure 1: The access-as-code loop: changes go through a pull request and a two-person review, a pipeline applies them in report-only mode first, a monitor compares the tenant with the baseline, and drift opens an issue that is closed in the repository or by reverting the tenant.

What goes in the repository

Every access object the program governs has a file in the repository, one file per object, named for the object’s display name. The safety rules travel with the files and are checked before merge.

Object class	Held as	Safety rule checked before merge
Conditional Access policies, named locations, authentication strengths	One JSON or HCL file per object	Every blocking or grant policy excludes the emergency access group (Chapter 07); new and changed policies deploy as report-only
PIM role settings for Entra roles and PIM for Groups	One file per role policy (the role’s rules)	Activation requires MFA or an authentication context, justification, and approval for Tier 0 roles; no rule permits a permanent active assignment except the documented emergency accounts (Chapter 08)
Eligible role assignments	One file per role, listing eligible groups	Eligibility goes to role-assignable groups, not individuals (Chapter 04)
Groups used for access	One file per group	Names follow the APP- convention; no nested members; dynamic rules only where the tier allows (Chapter 09)
Catalogs, access packages, assignment policies	One file per package with its policies	Expiry set (never “never”); approval chain matches the tier; incompatible packages listed both ways
Access review definitions	One file per review series	Fallback reviewer present whenever reviewers are managers or owners; auto-apply on; no-response default matches the schedule
Lifecycle Workflows	One file per workflow	Leaver workflows include “remove all access package assignments” and “revoke all refresh tokens”

Port authentication (802.1X) and certificate lifecycle automation are the other half of the identity-as-code work in the program’s compliance series; they are network and PKI subjects and stay there (Vol VI Book 02, with Vol I Book 02 and Vol I Book 03).

The tools, and where each one stands

Every tool below ends in Microsoft Graph, which is the only programmatic interface to these objects. The differences are in how much they cover, whether they hold state, and who maintains them.

Microsoft Graph and Microsoft Graph PowerShell

Graph exposes every object class in the table: Conditional Access policies, authentication strength policies, PIM role management policies and their rules, access packages and assignment policies, access review schedule definitions, and Lifecycle Workflows. Creating a Conditional Access policy needs Policy.Read.All and Policy.ReadWrite.ConditionalAccess, and Microsoft notes a known issue where the call can require consent to additional permissions.¹ PIM role settings are unifiedRoleManagementPolicy objects whose rules (approval, enablement, expiration, notification, and authentication context) are updated individually; managing the rules for Entra roles needs RoleManagementPolicy.ReadWrite.Directory, and Privileged Role Administrator is the least-privileged role for the task.² Access packages and policies need EntitlementManagement.ReadWrite.All, and access review definitions need AccessReview.ReadWrite.All.³⁴

Graph is the right tool for objects nothing else covers well, and for the read side of every check. It holds no state of its own, so “desired state” has to live in the repository and comparison has to be written.

The Terraform azuread provider

HashiCorp’s azuread provider was at v3.10.0 (September 24, 2026) as of October 2026.⁵ Its documented resources cover Conditional Access policies, named locations, authentication strength policies, groups and group members, administrative units, app role assignments, directory role eligibility schedule requests, PIM for Groups eligibility and assignment schedules, PIM for Groups role management policies, and catalogs, access packages, assignment policies, and their resource associations.⁶ The resource list has no access review definitions, no Lifecycle Workflows, and no role management policy for Entra directory roles (only for groups), so Entra role PIM settings, reviews, and workflows need another tool.⁷ The Conditional Access resource needs Policy.ReadWrite.ConditionalAccess and Policy.Read.All for a service principal, or the Conditional Access Administrator role for a user.⁸

Terraform holds state, which is its strength for drift: terraform plan -detailed-exitcode returns 0 when nothing differs and 2 when the plan has changes, and -refresh-only updates the state to match objects changed outside Terraform without changing them.⁹

Microsoft365DSC

Microsoft365DSC is an open-source PowerShell Desired State Configuration module for configuring, exporting, and monitoring Microsoft 365 tenants. As of October 2026 its repository lives in the Microsoft365DSC GitHub organization, is active, and released version 2.26.1015.1 on October 14, 2026.¹⁰¹¹ Its Entra resources include Conditional Access policies, authentication strength policies, role settings (PIM rules) for Entra roles and for PIM for Groups, role and group eligibility schedules, entitlement management catalogs, packages, assignment policies and connected organizations, access review definitions, and Lifecycle Workflows.¹² That makes it the one tool here that covers every object class in the table. The 2.x module expects PowerShell 7.6 or later for everything except compiling and applying configurations from Windows PowerShell.¹³ Treat it as a community project: check its release notes before every upgrade, and pin the version in the pipeline.

Microsoft Entra Tenant Governance configuration management

Configuration management in Microsoft Entra Tenant Governance is built on the Tenant Configuration Management APIs in Microsoft Graph, which are generally available.¹⁴ You write a baseline (a JSON list of resources and their desired property values, up to 200 resource instances each), a monitor checks the tenant against it, and every detected difference is reported as a drift object that lists each property whose value differs.¹⁵¹⁶ Its Entra resource types include Conditional Access policies, named locations, authentication strength and authentication method policies, groups, role definitions, role settings, role eligibility schedule requests, and entitlement management catalogs, packages, and assignment policies; access review definitions and Lifecycle Workflows aren’t among them as of October 2026.¹⁷

The limits shape how it is used:¹⁸¹⁹

Limit	Value
Monitors per tenant	30
Run interval	Every six hours, fixed
Resources monitored per day, per tenant	800 with P1 or P2; Entra ID Governance adds 10 a day per license
Snapshot extraction	20,000 resources a month (Governance adds 35 a month per license); 12 visible snapshot jobs
Snapshot retention	7 days
Fixed drift retention	Deleted 30 days after it is resolved
Baseline update	Deletes that monitor’s earlier results and drifts

Two of those rows are evidence rules in disguise. Snapshots and resolved drifts expire, and editing a baseline erases its history, so the pipeline exports every monitoring result and drift to the evidence store before it changes a baseline. Monitors report drift; correcting it is done with whatever tool owns the object, and the next run marks the drift fixed.²⁰

Microsoft Entra Exporter

Microsoft’s recoverability guidance recommends keeping known-good tenant states in a versioned repository, using the Tenant Configuration Management snapshot APIs for the resources they cover and Graph exports, for example with the open-source Microsoft Entra Exporter, for the rest. It also advises against merging extracts from different mechanisms, because a snapshot covers only the resources and properties its schema supports.²¹ The Exporter’s latest release was v3.0.1 (November 2025) as of October 2026.²²

Coverage, and the program’s choice

Object class	Graph	Terraform azuread	Microsoft365DSC	Tenant configuration monitoring
Conditional Access policies, named locations, authentication strengths	Yes	Yes	Yes	Yes
PIM role settings, Entra roles	Yes	No	Yes	Yes
PIM role settings, PIM for Groups	Yes	Yes	Yes	Not listed
Role eligibility	Yes	Yes	Yes	Yes
Groups	Yes	Yes	Yes	Yes
Catalogs, access packages, assignment policies	Yes	Yes	Yes	Yes
Access review definitions	Yes	No	Yes	No
Lifecycle Workflows	Yes	No	Yes	No

The table summarizes the tool references cited above. The program’s reference choice is a design position, made to minimize the number of write paths while keeping drift detection native:

• Write path: Microsoft365DSC, because it is the only declarative tool that covers every object class, so each object has exactly one tool that writes it. A team already invested in Terraform can use the azuread provider for the classes it covers and Microsoft Graph PowerShell scripts for PIM role settings, access reviews, and Lifecycle Workflows; the rule that matters is one writer per object class, recorded in the repository.
• Drift detection: Tenant configuration monitoring for every class it covers, because it runs inside the service and needs no pipeline to stay healthy; a scheduled read-only comparison (Terraform plan or a Microsoft365DSC export compared with the repository) for access reviews and Lifecycle Workflows.
• Backup export: Entra Exporter weekly, stored separately from the baselines, as Microsoft advises.

Illustrative code

Warning

The code in this chapter is illustrative. It hasn’t been tested against a production tenant. Review it, replace every placeholder, and run it against a test tenant before you use it.

A Conditional Access policy as Graph JSON

The compliance series’ illustrative policy needed three corrections. Graph identifies groups and authentication strengths by ID, not by name: the built-in phishing-resistant MFA strength is 00000000-0000-0000-0000-000000000004, and the excluded emergency access group must be its object ID.²³ And a new policy should first deploy as report-only (enabledForReportingButNotEnforced), not enabled.

{
  "displayName": "CA001 - Require phishing-resistant MFA for all resources",
  "state": "enabledForReportingButNotEnforced",
  "conditions": {
    "users": {
      "includeUsers": ["All"],
      "excludeGroups": ["<emergency-access-group-object-id>"]
    },
    "applications": {
      "includeApplications": ["All"]
    },
    "clientAppTypes": ["all"]
  },
  "grantControls": {
    "operator": "OR",
    "authenticationStrength": {
      "id": "00000000-0000-0000-0000-000000000004"
    }
  }
}

Held as a file, the exclusion is visible in the pull request, where a reviewer (or the check below) can confirm it is present and points at the right group. A portal screenshot can’t prove that over time. The production templates for the full policy library are in Appendix A.

The same policy in Terraform

In the azuread provider, a hard-coded authentication strength ID takes the /policies/authenticationStrengthPolicies/ prefix.²⁴

variable "emergency_access_group_id" {
  type        = string
  description = "Object ID of the emergency access (break-glass) group"
}

resource "azuread_conditional_access_policy" "ca001" {
  display_name = "CA001 - Require phishing-resistant MFA for all resources"
  state        = "enabledForReportingButNotEnforced"

  conditions {
    client_app_types = ["all"]

    applications {
      included_applications = ["All"]
    }

    users {
      included_users  = ["All"]
      excluded_groups = [var.emergency_access_group_id]
    }
  }

  grant_controls {
    operator                          = "OR"
    authentication_strength_policy_id = "/policies/authenticationStrengthPolicies/00000000-0000-0000-0000-000000000004"
  }
}

A pre-merge check for the emergency access exclusion

This check runs in the pull request pipeline against the JSON files in the repository. It reads files only and changes nothing.

#Requires -Version 7.0
# Federal Modernization Program: fail the build if any enabled or report-only
# Conditional Access policy in the repository doesn't exclude the emergency access group.
param(
    [Parameter(Mandatory)] [string] $PolicyPath,
    [Parameter(Mandatory)] [string] $EmergencyGroupId
)

$failures = foreach ($file in Get-ChildItem -Path $PolicyPath -Filter '*.json') {
    $policy = Get-Content -Path $file.FullName -Raw | ConvertFrom-Json
    if ($policy.state -eq 'disabled') { continue }

    $excluded = @($policy.conditions.users.excludeGroups)
    if ($excluded -notcontains $EmergencyGroupId) {
        [pscustomobject]@{
            File   = $file.Name
            Policy = $policy.displayName
            Reason = 'Emergency access group is not excluded'
        }
    }
}

if ($failures) {
    $failures | Format-Table -AutoSize
    throw "$(@($failures).Count) policy file(s) fail the emergency access exclusion check."
}
Write-Output 'All Conditional Access policy files exclude the emergency access group.'

An access review definition in Microsoft Graph PowerShell

A quarterly review of a Tier 1 application access group, reviewed by the group’s owners with a fallback reviewer, that removes denied members and, as the Chapter 09 schedule specifies for business applications, leaves unreviewed members unchanged. The shape follows Microsoft’s examples for New-MgIdentityGovernanceAccessReviewDefinition, and the scope and reviewer queries follow Microsoft’s security group tutorial and reviewer reference.²⁵²⁶²⁷

#Requires -Modules Microsoft.Graph.Identity.Governance
Connect-MgGraph -Scopes 'AccessReview.ReadWrite.All'

$groupId    = '<application-access-group-object-id>'
$fallbackId = '<backup-application-owner-object-id>'

$params = @{
    displayName          = 'Quarterly review - APP-PAYROLL-USERS-T1'
    descriptionForAdmins = 'Tier 1 application access; schedule in Book 04, Chapter 09'
    scope = @{
        '@odata.type' = '#microsoft.graph.accessReviewQueryScope'
        query         = "/groups/$groupId/transitiveMembers"
        queryType     = 'MicrosoftGraph'
    }
    reviewers = @(
        @{
            query     = "/groups/$groupId/owners"
            queryType = 'MicrosoftGraph'
        }
    )
    fallbackReviewers = @(
        @{
            query     = "/users/$fallbackId"
            queryType = 'MicrosoftGraph'
        }
    )
    settings = @{
        mailNotificationsEnabled        = $true
        reminderNotificationsEnabled    = $true
        justificationRequiredOnApproval = $true
        defaultDecisionEnabled          = $false
        instanceDurationInDays          = 14
        autoApplyDecisionsEnabled       = $true
        recommendationsEnabled          = $true
        recurrence = @{
            pattern = @{
                type       = 'absoluteMonthly'
                interval   = 3
                dayOfMonth = 1
            }
            range = @{
                type      = 'noEnd'
                startDate = '2027-01-01'
            }
        }
        applyActions = @(
            @{ '@odata.type' = '#microsoft.graph.removeAccessApplyAction' }
        )
    }
}

New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter $params

With defaultDecisionEnabled set to $false, members nobody reviewed keep their access, and the escalation to the governance office is a follow-up on the review’s “not reviewed” results. For privileged-role and guest reviews, set defaultDecisionEnabled = $true and defaultDecision = 'Deny'.

Change control

The repository is the only normal path to production. The rules below are design positions; together they are how the program meets CM-3 and CM-5 for the identity plane and the FedRAMP 20x change-management indicators, which ask that changes be logged and monitored, that machine-based resources be changed by redeploying version-controlled definitions rather than by editing in place where reasonable, and that testing and validation during deployment be automated.²⁸

1. Two people per change. The author of a pull request can’t approve it. Changes to Tier 0 objects (emergency access exclusions, PIM settings for Tier 0 roles, the pipeline’s own permissions) need a second approver from the security team.
2. Checks before merge. Schema validation, the emergency access exclusion check, the safety rules in the object table, and a plan or dry run whose output is attached to the pull request.
3. Report-only first. New and changed Conditional Access policies deploy as report-only, run at least a week against the sign-in logs (the Conditional Access insights workbook in Book 02, Chapter 10), and are switched to enabled in a second pull request that cites the impact review.
4. A pipeline identity with no secret. The pipeline signs in as a service principal with workload identity federation (Chapter 05) and holds only the Graph permissions its object classes need. That service principal can change every access policy in the tenant, so it is a Tier 0 asset: it has two owners, its permissions are reviewed quarterly, and a Conditional Access policy for workload identities restricts where it can sign in from.
5. Emergency changes. During an incident, an administrator may change a policy in the portal under a PIM activation with a ticket number as justification. The change is back-ported to the repository within one business day. Until then the drift monitor reports it, which is the point: an emergency change that never reaches the repository stays visible.
6. Rollback is a revert. Undoing a change means reverting its commit and redeploying, so the rollback has the same record as the change.

Drift detection and closure

Code governs the policy, but a Global Administrator can still change the tenant directly. Drift detection is the control that catches those changes, and the design rule is the one Book 03, Chapter 11 uses: close each finding at the source, never by editing the copy.

Object classes	Detector	Cadence	Output
Conditional Access, authentication strengths, named locations, role settings, role eligibility, groups, access packages and policies	Tenant configuration monitor against the repository’s baseline	Every six hours (fixed)	Drift objects with the differing properties, exported to the evidence store
Access review definitions, Lifecycle Workflows	Scheduled read-only comparison (Microsoft365DSC export, or terraform plan -detailed-exitcode where Terraform owns the object)	Daily	Diff attached to an issue when anything differs
Directory objects outside both	Identity assessment baseline in Git (Book 02, Chapter 10)	Weekly	Drift report and an issue
Whole tenant, for recovery	Entra Exporter	Weekly	Export kept separately from baselines

Every drift is one of two things, and the issue records which:

• Unauthorized or accidental. Redeploy the repository’s version, which closes the drift on the next monitor run, and investigate who made the change from the audit log.
• Intended but not yet in code. Usually an emergency change. Back-port it through a pull request, which updates the baseline. Export the monitor’s results first, because a baseline update deletes them.

A drift open for more than one business day is reported to the governance office. A drift on a Tier 0 object (an emergency access exclusion removed, a PIM approval rule relaxed) is a security incident.

What the assessor reads

Configuration evidence proves a setting existed. Operational evidence proves the setting did its job. An assessor needs both, and needs them for the whole assessment period, not just the day of the visit.

Figure 2: Three kinds of record support the access controls: configuration files support enforcement controls, records of use support account-management and review controls, and drift and change records support continuous monitoring.

Control mapping

The control statements are summarized from the NIST SP 800-53 Rev. 5 catalog (release 5.2.0) as FedRAMP publishes it.^29303132 FedRAMP doesn’t set the AC-2 account-review frequency or the AC-6(7) privilege-review frequency; both stay organization-defined, so the system security plan states the program’s schedule from Chapter 09.³³ The mechanisms and evidence are the program’s.

Control	What it requires (summary)	How the program meets it	Evidence the assessor reads
AC-2 Account Management	Define account types, require approvals for account and group membership, create, modify, disable, and remove accounts per policy, monitor use, review accounts at a defined frequency, and align account management with personnel termination and transfer	HR-driven provisioning and Lifecycle Workflows (Book 03); access packages with approval and expiry; scheduled access reviews	Package policies in the repository; entitlement management audit records per request; review history reports; Lifecycle Workflows run history
AC-2(4) Automated Audit Actions	Automatically audit account creation, modification, enabling, disabling, and removal	Entra audit log streamed to the workspace with one-year retention	Workspace retention setting; sample audit queries for each action
AC-3 Access Enforcement	Enforce approved authorizations for logical access	Conditional Access policies and group-based application assignment	Policy files and their deployment history; tenant configuration monitor results showing no unresolved drift; sign-in logs showing policies applied
AC-5 Separation of Duties	Document duties and define access authorizations that support separating them	Three-party group model; incompatible access packages; two-person pull requests	Incompatibility settings in package files; pull request approvals showing author and approver differ
AC-6 Least Privilege	Allow only the access users need for assigned tasks	PIM eligibility instead of standing roles; tiered packages with expiry	PIM role settings files; eligible and active assignment reports; package expiry settings
AC-6(7) Review of User Privileges	Review privileges assigned to roles and classes of users at a defined frequency; reassign or remove as needed	Quarterly PIM role reviews with auto-apply	PIM review results and applied removals for each quarter
IA-2, IA-2(1), IA-2(2) Identification and Authentication	Uniquely identify and authenticate users; MFA for privileged and non-privileged accounts, which FedRAMP’s guidance says must be phishing-resistant per current CISA guidance	Conditional Access with the phishing-resistant authentication strength (Chapter 07)	Policy files; sign-in logs showing the authentication strength satisfied; the authentication methods registration report
CA-7 Continuous Monitoring	A system-level continuous monitoring strategy: defined metrics, monitoring and assessment frequencies, ongoing assessment and monitoring, correlation and analysis, response actions, and status reporting	Six-hourly configuration monitoring; daily comparisons for the rest; drift issues with resolution records; review completion metrics	Exported monitoring results and drift objects; issue history; the monthly governance metrics below

FedRAMP 20x indicators

Under FedRAMP 20x the same records support Key Security Indicators. The indicator IDs, titles, and statements are from FedRAMP’s published pages; which records support which indicator is the program’s mapping.³⁴³⁵

Indicator	What it asks	Records from this book
KSI-IAM-AAM Automating Account Management	Account, role, and group lifecycles and privileges are managed through automation	Lifecycle Workflows runs; package assignment and expiry records; review auto-apply results
KSI-IAM-ELP Ensuring Least Privilege	Access is limited to what each user or device needs, and continuously reviewed	Tiered packages; review history; separation-of-duties settings
KSI-IAM-JIT Authorizing Just-in-Time	A least-privilege, just-in-time authorization model, continuously reviewed	PIM settings files; activation audit records; quarterly PIM reviews
KSI-IAM-APM Adopting Passwordless Methods	Passwordless where feasible, otherwise phishing-resistant MFA	Conditional Access authentication strength policies and sign-in evidence
KSI-CMT-LMC Logging Changes	Changes to the offering are logged and monitored	Pull requests, pipeline runs, Entra audit records, drift monitoring
KSI-CMT-RMV Redeploying vs Modifying	Changes go through redeploying version-controlled resources where reasonable	The repository as the only normal path; emergency changes back-ported
KSI-CMT-VTD Validating Throughout Deployment	Testing and validation of changes during deployment is automated	Pre-merge checks; report-only stage; plan output attached to each pull request

The compliance series takes these records further, into the evidence contract and the attestation loop (Vol VI Book 07, Vol VII Book 04), and its governance book carries the program’s control contract for lifecycle automation and certification campaigns (Vol IX Book 06).

The evidence package for a period

For each month, the pipeline assembles the period’s records in the evidence store, and the governance office signs off the monthly metrics:

Item	Source
The repository’s state at period end, and every merged pull request with its approvals	Git host
Pipeline runs, with plan or dry-run output	Pipeline logs
Monitoring results and drift objects, with each drift’s resolution	Tenant configuration monitoring, exported
Review history reports and per-instance results for reviews that closed in the period	Access reviews, exported (Chapter 09)
Entitlement management and PIM audit records	Log Analytics workspace
The exception register, with changes in the period	Governance office
Metrics: reviews completed on time; denials applied within five business days; packages without expiry (target zero); drift open more than one business day; emergency changes back-ported within one business day	Computed from the records above

Honest limits

• Code governs the definition, not the use. A correct policy file says nothing about whether reviewers read what they approved; the review history and the bulk-decision check in Chapter 09 carry that part.
• The emergency access exclusion is a deliberate hole in every policy. Its use is a critical detection (Book 02, Chapter 10), and its accounts are documented in the system security plan (Chapter 02).
• Tool coverage moves. Each tool’s resource list changes with its releases; re-check the coverage table at every upgrade and whenever Microsoft adds an object class.
• Native retention is short. Everything in the evidence package that comes from Entra ID has to be exported before Microsoft’s retention window closes, or it is gone.

Where to go next

• Book 02 — Identity & Directory builds the tenant this book governs: the Conditional Access framework and PIM baseline (Chapter 09), and monitoring, log retention, and Git-based drift detection (Chapter 10).
• Book 03 — HR-Driven Identity owns the attributes and the joiner, mover, and leaver lifecycle that access packages, automatic assignment, and Lifecycle Workflows depend on.

TipContinue the book

← Previous: Chapter 09 — Access Governance: Packages, Reviews and Lifecycle · Book index · Next: Appendix A — Conditional Access Policy Templates →

---

1. Microsoft Learn, “Create conditionalAccessPolicy,” https://learn.microsoft.com/graph/api/conditionalaccessroot-post-policies?view=graph-rest-1.0 (accessed Oct 20, 2026).

2. Microsoft Learn, “Update rules in PIM by using Microsoft Graph,” https://learn.microsoft.com/graph/how-to-pim-update-rules (accessed Oct 20, 2026).

3. Microsoft Learn, “Change request settings for an access package in entitlement management,” https://learn.microsoft.com/entra/id-governance/entitlement-management-access-package-request-policy (accessed Oct 20, 2026).

4. Microsoft Learn, “Create an access review of groups and applications in Microsoft Entra ID,” https://learn.microsoft.com/entra/id-governance/create-access-review (accessed Oct 20, 2026).

5. HashiCorp, terraform-provider-azuread releases (v3.10.0), https://github.com/hashicorp/terraform-provider-azuread/releases (accessed Oct 20, 2026).

6. HashiCorp, terraform-provider-azuread resource documentation index, https://github.com/hashicorp/terraform-provider-azuread/tree/main/docs/resources (accessed Oct 20, 2026).

7. HashiCorp, terraform-provider-azuread resource documentation index, https://github.com/hashicorp/terraform-provider-azuread/tree/main/docs/resources (accessed Oct 20, 2026).

8. HashiCorp, “azuread_conditional_access_policy” resource documentation, https://github.com/hashicorp/terraform-provider-azuread/blob/main/docs/resources/conditional_access_policy.md (accessed Oct 20, 2026).

9. HashiCorp, “terraform plan command reference,” https://developer.hashicorp.com/terraform/cli/commands/plan (accessed Oct 20, 2026).

10. Microsoft365DSC, repository README, https://github.com/Microsoft365DSC/Microsoft365DSC (accessed Oct 20, 2026).

11. Microsoft365DSC, release 2.26.1015.1, https://github.com/Microsoft365DSC/Microsoft365DSC/releases (accessed Oct 20, 2026).

12. Microsoft365DSC, DSC resource modules, https://github.com/Microsoft365DSC/Microsoft365DSC/tree/dev/Modules/Microsoft365DSC/DscResources (accessed Oct 20, 2026).

13. Microsoft365DSC, Show-PwshWarning.ps1 (PowerShell version requirement), https://github.com/Microsoft365DSC/Microsoft365DSC/blob/dev/Modules/Microsoft365DSC/Show-PwshWarning.ps1 (accessed Oct 20, 2026).

14. Microsoft Learn, “Configuration management” (Microsoft Entra Tenant Governance), https://learn.microsoft.com/entra/id-governance/tenant-governance/configuration-management (accessed Oct 20, 2026).

15. Microsoft Learn, “Configuration management” (Microsoft Entra Tenant Governance), https://learn.microsoft.com/entra/id-governance/tenant-governance/configuration-management (accessed Oct 20, 2026).

16. Microsoft Learn, “Deploy Microsoft Entra Tenant Governance end to end,” https://learn.microsoft.com/entra/id-governance/tenant-governance/deployment-guide (accessed Oct 20, 2026).

17. Microsoft Learn, “Supported Microsoft Entra resources for Tenant Configuration Management,” https://learn.microsoft.com/graph/utcm-entra-resources (accessed Oct 20, 2026).

18. Microsoft Learn, “Use the Tenant Configuration Management APIs in Microsoft Graph,” https://learn.microsoft.com/graph/api/resources/unified-tenant-configuration-management-api-overview?view=graph-rest-1.0 (accessed Oct 20, 2026).

19. Microsoft Learn, “Licensing for Microsoft Entra Tenant Governance,” https://learn.microsoft.com/entra/id-governance/tenant-governance/licensing (accessed Oct 20, 2026).

20. Microsoft Learn, “Frequently asked questions for Microsoft Entra Tenant Governance,” https://learn.microsoft.com/entra/id-governance/tenant-governance/faq (accessed Oct 20, 2026).

21. Microsoft Learn, “Recoverability best practices,” https://learn.microsoft.com/entra/architecture/recoverability-overview (accessed Oct 20, 2026).

22. Microsoft, Microsoft Entra Exporter repository and releases, https://github.com/microsoft/EntraExporter (accessed Oct 20, 2026).

23. Microsoft Learn, “List authenticationStrengthPolicies,” https://learn.microsoft.com/graph/api/authenticationstrengthroot-list-policies?view=graph-rest-1.0 (accessed Oct 20, 2026).

24. HashiCorp, “azuread_conditional_access_policy” resource documentation, https://github.com/hashicorp/terraform-provider-azuread/blob/main/docs/resources/conditional_access_policy.md (accessed Oct 20, 2026).

25. Microsoft Learn, “New-MgIdentityGovernanceAccessReviewDefinition,” https://learn.microsoft.com/powershell/module/microsoft.graph.identity.governance/new-mgidentitygovernanceaccessreviewdefinition?view=graph-powershell-1.0 (accessed Oct 20, 2026).

26. Microsoft Learn, “Review access to security groups using access reviews APIs,” https://learn.microsoft.com/graph/tutorial-accessreviews-securitygroup (accessed Oct 20, 2026).

27. Microsoft Learn, “Configure access reviewers using access reviews APIs,” https://learn.microsoft.com/graph/accessreviews-reviewers-concept (accessed Oct 20, 2026).

28. FedRAMP, “Change Management” (FedRAMP 20x Key Security Indicators, Consolidated Rules for 2026), https://fedramp.gov/2026/providers/20x/key-security-indicators/change-management/ (accessed Oct 20, 2026).

29. National Institute of Standards and Technology, SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations, September 2020 (with release 5.2.0, August 27, 2025), https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final (accessed Oct 20, 2026).

30. FedRAMP, “Access Control” (NIST SP 800-53 Rev. 5 controls, catalog release 5.2.0), https://fedramp.gov/2026/reference/controls/access-control/ (accessed Oct 20, 2026).

31. FedRAMP, “Identification and Authentication” (NIST SP 800-53 Rev. 5 controls, catalog release 5.2.0), https://fedramp.gov/2026/reference/controls/identification-and-authentication/ (accessed Oct 20, 2026).

32. FedRAMP, “Assessment, Authorization, and Monitoring” (NIST SP 800-53 Rev. 5 controls, catalog release 5.2.0), https://fedramp.gov/2026/reference/controls/assessment-authorization-and-monitoring/ (accessed Oct 20, 2026).

33. FedRAMP, “Access Control” (NIST SP 800-53 Rev. 5 controls, catalog release 5.2.0), https://fedramp.gov/2026/reference/controls/access-control/ (accessed Oct 20, 2026).

34. FedRAMP, “Identity and Access Management” (FedRAMP 20x Key Security Indicators, Consolidated Rules for 2026), https://fedramp.gov/2026/providers/20x/key-security-indicators/identity-and-access-management/ (accessed Oct 20, 2026).

35. FedRAMP, “Change Management” (FedRAMP 20x Key Security Indicators, Consolidated Rules for 2026), https://fedramp.gov/2026/providers/20x/key-security-indicators/change-management/ (accessed Oct 20, 2026).