PIM iteration 2-API's stoppen in oktober 2026: zo vind je wat ze nog aanroept

30-10-2025 · Samantha Kloos-Kilkens

Microsoft heeft nu een datum gekoppeld aan het einde van de iteration 2-API's van Privileged Identity Management, alles onder /beta/privilegedAccess: vanaf 28 oktober 2026 mislukken aanroepen naar die endpoints. Bijna niemand schrijft er nog nieuwe code tegen, en juist dat maakt deze uitfasering lastig: wat ze nog aanroept is oud, draait vaak onbeheerd met hoge rechten en is meestal geschreven door iemand die allang iets anders doet. In deze blog: hoe je die aanroepers vindt met Microsoft Graph activity logs, permission grants, sign-in logs en code search, en hoe de iteration 3-vervangers eruitzien voor Entra-rollen, groepen en Azure-resources.

Een oud bedieningspaneel met tuimelschakelaars en knoppen Foto: Fellipe Ditadi via Unsplash

Wat Microsoft heeft aangekondigd

MC1181281, gepubliceerd op 29 oktober 2025, meldt dat vanaf 28 oktober 2026 alle applicaties en scripts die de PIM iteration 2-API's (beta) voor Azure-resources, Microsoft Entra-rollen en groepen aanroepen, zullen falen omdat de aanroepen geen data meer teruggeven. Microsoft vraagt je te stoppen met nieuwe ontwikkeling op iteration 2 en over te stappen op de iteration 3-API's, die generally available zijn. Op het moment van schrijven lopen de Learn-pagina's nog achter: het iteration 2-overzicht in de Graph beta-referentie zegt nog dat de API "will be deprecated soon", en de pagina met PIM API-concepten houdt het op "will eventually be deprecated". Een datum stond er tot nu toe nergens bij.

Ter oriëntatie: iteration 2 is de API onder /beta/privilegedAccess met de providersegmenten aadRoles en azureResources (plus het ongedocumenteerde aadGroups voor groepen, dat MC1181281 ook noemt), gebouwd op resources als governanceResource, governanceRoleDefinition, governanceRoleSetting, governanceRoleAssignment en governanceRoleAssignmentRequest. Hij is nooit GA geworden. Iteration 1 (/beta/privilegedRoles) is al in juni 2021 deprecated en wordt niet meer ondersteund.

Twee details zijn belangrijk voordat je gaat zoeken. Het eerste is een naamvalkuil: de iteration 3-API voor PIM for Groups zit op /identityGovernance/privilegedAccess/group/..., dus wie simpelweg op "privilegedAccess" zoekt, vindt ook code die al gemigreerd is. Waar je naar zoekt is privilegedAccess direct na /beta/. Het tweede is hoe het misgaat. "Geen data meer teruggeven" zegt niets over de vraag of je script een fout gooit of stilletjes niets ontvangt, en een compliancerapport dat ineens nul eligible assignments toont is erger dan een rapport dat crasht.

Waar iteration 2-aanroepen zich meestal verstoppen

De voor de hand liggende kandidaten zijn PowerShell-scripts op de AzureADPreview-module, waarvan de PIM-cmdlets (Get-AzureADMSPrivilegedResource, Get-AzureADMSPrivilegedRoleSetting, Open-AzureADMSPrivilegedRoleAssignmentRequest en de rest van de AzureADMSPrivileged-familie, met -ProviderId aadRoles of azureResources) op iteration 2 draaien. De AzureAD-modules worden sinds 30 maart 2025 toch al niet meer ondersteund, en Microsofts migratiehandleiding voor PIM PowerShell koppelt de cmdlets voor Azure-resources aan hun tegenhangers in Az.Resources.

Minder voor de hand liggend is de bètamodule van Microsoft Entra PowerShell, de aanbevolen opvolger van AzureADPreview. Get-EntraBetaPrivilegedResource, Get-EntraBetaPrivilegedRoleDefinition, Get-EntraBetaPrivilegedRoleSetting en Set-EntraBetaPrivilegedRoleSetting nemen een -ProviderId zoals aadRoles en roepen dezelfde /beta/privilegedAccess-endpoints aan als de Graph PowerShell beta-cmdlets uit de *-MgBetaPrivilegedAccess*-familie, zoals Get-MgBetaPrivilegedAccessResource en Update-MgBetaPrivilegedAccessRoleSetting. Dat is iteration 2. Een script dat dit jaar netjes van AzureADPreview naar Entra PowerShell is overgezet, kan dus van de ene uitgefaseerde API naar precies dezelfde uitgefaseerde API zijn verhuisd. Handige vuistregel in de Graph SDK: de iteration 3-cmdlets voor groepen hebben IdentityGovernance in hun naam (New-MgIdentityGovernancePrivilegedAccessGroupEligibilityScheduleRequest), de iteration 2-cmdlets niet.

Buiten PowerShell zou ik kijken naar Logic Apps en Power Automate-flows met HTTP-acties richting Graph beta, Azure Automation-runbooks, activatiehulpjes die aan een ticketsysteem hangen, en PAM- of governancetools van derden die met PIM integreerden in de jaren dat iteration 2 de enige API was die ook Azure-resources afdekte.

Aanroepers vinden in de Microsoft Graph activity logs

De betrouwbaarste bron zijn de Microsoft Graph activity logs, die elk request vastleggen dat Graph voor je tenant verwerkt, inclusief de volledige request-URI. Je hebt Entra ID P1 nodig en een diagnostic setting die de categorie MicrosoftGraphActivityLogs naar een Log Analytics-workspace stuurt. Logging begint pas op het moment dat je hem aanzet, dus staat hij nog uit, dan is aanzetten de eerste stap: met een jaar aanloop vang je ook jobs die maandelijks, per kwartaal of één keer per jaar draaien, zoals een jaarlijkse export voor hercertificering.
MicrosoftGraphActivityLogs
| where TimeGenerated > ago(30d)
| extend Path = tolower(replace_regex(tostring(parse_url(RequestUri).Path), @'/+', '/'))
| where Path startswith "/beta/privilegedaccess"
| summarize Requests = count(), LastSeen = max(TimeGenerated),
    Methods = make_set(RequestMethod), Paths = make_set(Path, 10),
    UserAgents = make_set(UserAgent, 5)
    by AppId, ServicePrincipalId, UserId
| sort by Requests desc
AppId en ServicePrincipalId identificeren de client. Is UserId gevuld, dan gaat het om delegated access, meestal iemand die interactief een script draait; is hij leeg, dan is het app-only, meestal een runbook, een Logic App of een service. Aan de user agent zie je doorgaans of het de Graph PowerShell SDK is of iets anders. Duikt er een first-party client van Microsoft op, zoals de Azure portal, dan is dat Microsofts migratie en niet de jouwe.

Permission grants en sign-in logs als tweede vangnet

Iteration 2 heeft zes eigen Graph-permissies: PrivilegedAccess.Read en PrivilegedAccess.ReadWrite, elk voor AzureAD, AzureADGroup en AzureResources. Iteration 3 gebruikt andere (RoleManagement.\, RoleEligibilitySchedule.\ en RoleAssignmentSchedule.\* voor directory-rollen, PrivilegedEligibilitySchedule.\* en PrivilegedAssignmentSchedule.\* voor groepen) en voor Azure-resources helemaal geen Graph-permissie. Een app met een PrivilegedAccess.\*-grant is dus een sterke aanwijzing. Geen bewijs, want grants leven langer dan de code die ze nodig had, maar het levert een lijst op die niet afhangt van de bewaartermijn van je logs.
Connect-MgGraph -Scopes "Application.Read.All", "Directory.Read.All"

$graphSp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
$pattern = '^PrivilegedAccess\.(Read|ReadWrite)\.(AzureAD|AzureADGroup|AzureResources)$'
$roleNames = @{}
$graphSp.AppRoles | ForEach-Object { $roleNames[$_.Id] = $_.Value }

$appHits = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $graphSp.Id -All |
    Where-Object { $roleNames[$_.AppRoleId] -match $pattern } |
    Select-Object @{ n = 'Client'; e = { $_.PrincipalDisplayName } }, PrincipalId,
        @{ n = 'Type'; e = { 'Application' } }, @{ n = 'Permission'; e = { $roleNames[$_.AppRoleId] } }

$delegatedHits = Get-MgOauth2PermissionGrant -Filter "resourceId eq '$($graphSp.Id)'" -All |
    ForEach-Object {
        $grant = $_
        $grant.Scope -split ' ' | Where-Object { $_ -match $pattern } | ForEach-Object {
            [pscustomobject]@{
                Client      = (Get-MgServicePrincipal -ServicePrincipalId $grant.ClientId).DisplayName
                PrincipalId = $grant.ClientId
                Type        = "Delegated ($($grant.ConsentType))"
                Permission  = $_
            }
        }
    } | Sort-Object PrincipalId, Type, Permission -Unique

@($appHits) + @($delegatedHits) | Sort-Object Client | Format-Table -AutoSize
Voor elke hit laten de service principal sign-in logs (en voor runbooks en Logic Apps met een managed identity de managed identity sign-in logs) zien of de app nog tokens voor Microsoft Graph aanvraagt, hoe vaak en vanaf welke IP-adressen. Welk endpoint er is aangeroepen staat niet in de sign-in logs, dus op zichzelf bewijzen ze geen iteration 2-gebruik, maar samen met de grant vertellen ze je welke aanwijzingen nog leven. Is de client een multitenant-app van een leverancier, vraag die leverancier dan schriftelijk naar hun datum voor iteration 3.

Voor de broncode zoek je in repositories, geëxporteerde runbooks en Logic App-definities (exporteer de workflow als ARM-template) naar beta/privilegedAccess/, governanceRole, AzureADMSPrivileged, MgBetaPrivilegedAccess en EntraBetaPrivileged.

Hoe de iteration 3-tegenhangers eruitzien

De iteration 3-API's splitsen elke provider op in aparte request-resources voor eligibility en voor actieve toewijzingen, en halen Azure-resources helemaal uit Graph:
  • Microsoft Entra-rollen: /roleManagement/directory/roleEligibilityScheduleRequests voor eligible assignments en /roleManagement/directory/roleAssignmentScheduleRequests voor actieve toewijzingen en activaties, met de actuele stand in de bijbehorende *ScheduleInstances. De scope is een directoryScopeId (/ of een administrative unit) in plaats van een governanceResource voor de tenant. Rolinstellingen verhuizen naar /policies/roleManagementPolicies en /policies/roleManagementPolicyAssignments met scopeType DirectoryRole.
  • PIM for Groups: /identityGovernance/privilegedAccess/group/eligibilityScheduleRequests en .../assignmentScheduleRequests, met accessId member of owner, en policies met scopeType Group. Zie het overzicht van de PIM for Groups-API's.
  • Azure-resources: Azure Resource Manager, niet Graph. Microsoft.Authorization/roleEligibilityScheduleRequests, roleAssignmentScheduleRequests en roleManagementPolicies op de scope van management group, subscription, resource group of resource (api-version 2020-10-01, zie het REST-voorbeeld), of New-AzRoleEligibilityScheduleRequest en Update-AzRoleManagementPolicy in Az.Resources. Er is geen registratiestap meer, en de aanroeper heeft een ARM-token nodig plus Owner of User Access Administrator op de scope in plaats van een Graph-permissie. Voor een app registration betekent dat: de PrivilegedAccess.\*.AzureResources-grant weghalen en de service principal een Azure-rol geven.
Diagram dat het PIM iteration 2-endpoint in Graph beta onder /beta/privilegedAccess koppelt aan de iteration 3-vervangers: Graph role management-API's voor Entra-rollen, Graph identity governance-API's voor PIM for Groups en Azure Resource Manager voor Azure-resources, met de permissies die elk nodig heeft.
Ook de semantiek verandert. Iteration 2 combineerde een request-type met een assignmentState (UserAdd plus Active is een activatie, AdminAdd plus Eligible maakt iemand eligible); iteration 3 werkt met action-waarden als adminAssign, adminRemove, selfActivate en selfDeactivate op de eligibility- of assignment-request-resource. Rolinstellingen worden 17 regels met vaste ID's zoals Expiration_EndUser_Assignment en Approval_EndUser_Assignment, die in Rules in PIM aan het admin center gekoppeld worden. Een typisch hulpje voor zelfactivatie ziet er in iteration 3 zo uit:
Connect-MgGraph -Scopes "RoleAssignmentSchedule.ReadWrite.Directory"
$me = (Invoke-MgGraphRequest -Method GET -Uri '/v1.0/me?$select=id').id

$params = @{
    Action           = "selfActivate"
    PrincipalId      = $me
    RoleDefinitionId = "fe930be7-5e62-47db-91af-98c3a49a38b1"   # User Administrator
    DirectoryScopeId = "/"
    Justification    = "CHG0001234"
    ScheduleInfo     = @{
        StartDateTime = (Get-Date).ToUniversalTime()
        Expiration    = @{ Type = "AfterDuration"; Duration = "PT2H" }
    }
}
New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params
Zet nu de diagnostic setting voor de Graph activity logs aan, draai de permissie-inventarisatie ernaast, en zet elke app die in een van beide lijsten opduikt op een migratiebord met een eigenaar en een streefdatum ruim voor de zomer van 2026, zodat ook de jobs die maar één keer per kwartaal draaien op tijd boven water komen.

Update mei 2026: Microsoft heeft op de pagina met PIM API-concepten een zin toegevoegd dat het de gebruikersinterface van PIM zelf nog naar de iteration 3-API's aan het migreren is. Toont de query op de activity logs hits van Microsofts eigen admin-portalclients, laat die dan buiten je migratielijst en richt je op je eigen apps. Zie Privileged Identity Management APIs.

Geschreven door een expert van Argus IT

Zo’n expert in je team, of zelf zo werken in security, IAM of cloud?

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens

Samantha Kloos-Kilkens werkt al meer dan tien jaar in security en identity, waarvan acht jaar bij Microsoft in de productgroep Identity and Network Access. In 2023 richtte ze Argus IT op en ze heeft een zwak voor de verborgen pareltjes in Entra ID. CISSP, CCSP, CISM, CCSK en Microsoft Certified Trainer.

Blijf op de hoogte

Schrijf je in voor onze nieuwsbrief en ontvang een seintje wanneer we een nieuw artikel publiceren of nieuws te delen hebben.