Elevation Window Auditor

Normalizes time-boxed privileged elevations from Entra ID PIM, AWS IAM Identity Center, and Okta Privileged Access into one ledger, and flags the ones still active past their approved window, missing a required justification or ticket, or granted with no window at all.

Date: 2026-11-05 Theme: Detect + Protect Type: Web App Platform: PIM / JIT Access Status: Prototype

What it is

A single-page console that loads elevation events from three platforms into one normalized table, computes six policy checks against each record, and opens with a banner naming the worst case instead of making the reader scroll for it. Click any row to see why it was flagged, in plain language tied to the actual field values, plus the raw adapter-shaped payload behind it.

Who it serves

The security engineer who owns PIM policy, the on-call lead who approves break-glass activations, or whoever has to answer "was anyone holding admin longer than they should have?" after an incident review. Also useful heading into a SOX or ISO 27001 walkthrough, where "show me every elevated session from the quarter and what it was for" is exactly the question an auditor asks.

The IAM pain it addresses

Entra PIM's own documentation says a deactivated role is removed from the active assignment within seconds. But it also admits the catch: if a downstream application cached the fact that a user held a role, the user "may still get access" after that role deactivates, and the fix depends on the application's own architecture. That's a real gap between what the PIM schedule says happened and what a connector reading from a downstream system actually observes, and nothing in the PIM console itself tells you where that gap exists across your own fleet of integrations.

AWS and Okta each have a version of the same problem from a different angle. AWS IAM Identity Center enforces a hard session cap of 12 hours per permission set, but it ships no approval workflow of its own. Microsoft's own blog on bridging Entra PIM into IAM Identity Center is explicit that the approval step comes from PIM, not from AWS. AWS's CloudTrail AssumeRole event carries the credential's expiration timestamp inside the response, but there's no separate "session expired" event to tell you it actually ended on schedule — you'd have to go looking for API calls made after that timestamp to know if it didn't. Okta Privileged Access is a distinct, separately licensed product from core Okta, and its own marketing page is the only place that spells out that access is time-bound and expires automatically. Useful, but it still leaves the "did it actually expire" question to whoever bothers to check the session log.

None of the three platforms will tell you, on their own, whether an elevation someone approved for ninety minutes is still sitting open six hours later. The sample data seeds exactly that case: alice.renner@example.com activated Global Administrator in Entra PIM for a four-hour window to roll back a Conditional Access policy after an SSO outage, with a ticket and an approver attached — and the last read from the connector, four hours after that window closed, still shows the assignment active. That's the record the banner names on load.

How it works

• Ledger table. Every elevation from all three adapters in one sortable list — platform, principal, role or resource, activation time, expected expiry, last observed state, and flags. Flagged rows sort to the top.
• Worst-case banner. If any record is still active past its expected expiry, that's the headline, ranked by how far past expiry it is — not just whichever record happens to carry the most flags. A standing SSH grant with no window is a real problem too, but a Global Admin session that outlived its approval by six hours is the one that gets read first.
• Search and filter. Text search across principal and role, a platform dropdown, and a flagged-only toggle.
• Detail panel. Selecting a record shows every field, which of the six checks fired and why (quoting the actual duration, ticket, or approver value involved), and the adapter-shaped raw event behind it — a Graph unifiedRoleAssignmentScheduleRequest, a CloudTrail AssumeRole record, or an Okta Privileged Access grant event. Each snippet carries a visible note that it's structurally illustrative and needs validating against a real tenant before anyone treats it as paste-ready.
• Demo revoke. A "Revoke now" button on flagged, still-active records appends to a local action log and flips the record's observed state. It doesn't call any platform API — this is a prototype, and the button says so.

What's in this folder

• README.md — this file
• cover-image.png — cover art for the idea's card and detail page
• metadata.md — generation metadata and sourcing
• requirements.md — the normalized elevation schema, the six flag rules with their exact conditions, and the banner's tie-break logic
• index.html — the single-page app; carries an inline copy of the sample data so it still runs if fetch() of local JSON is blocked under file://
• style.css — layout and the navy/electric-blue/teal visual treatment
• script.js — data loading, the flag computation, filtering, detail rendering, and the demo revoke action
• sample-data.json — 16 elevations across the three adapters: 10 carry at least one flag, 6 are clean controls so the reader can see what "fine" looks like next to what isn't

How to run / read it

Open index.html in any modern browser. No build step, no server, no login.

Estimated impact

No measured number — this is a prototype, not a result from a live deployment. The credible claim is narrower and still worth stating: once a security team is running PIM, IAM Identity Center, and Okta Privileged Access at once, the only way today to catch an overrun elevation is someone manually cross-referencing three consoles' session logs against three sets of approval records, and that check almost never happens outside of an incident post-mortem. A tool that runs the six comparisons automatically turns that into something that can run every time an access review is due, not just after something has already gone wrong.

Adapters and scale

Three adapters, each reading a documented API or log surface: Entra ID PIM (Graph unifiedRoleEligibilityScheduleRequest and unifiedRoleAssignmentScheduleRequest, including scheduleInfo.expiration and ticketInfo), AWS IAM Identity Center (permission-set session duration settings plus CloudTrail AssumeRole events), and Okta Privileged Access (its grant-activation log). None of these require a full identity sync — only the activation/session events for a time window, which is what makes this hold up at 50k+ identities and 500+ apps: the volume driver is elevations per day across whatever subset of tier-0 roles and resources an org actually gates behind JIT, not total headcount. A one-person security team checking three consoles by hand doesn't scale past a handful of elevations a week; a script pulling the same three event feeds does, regardless of how many identities sit behind them.

Sources

1. Official documentation / standards:
   • https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-how-to-activate-role — confirms PIM removes an active assignment "within seconds" of deactivation or expiration, and documents the downstream application-caching gap that can leave access visible after a role deactivates
   • https://learn.microsoft.com/en-us/graph/api/resources/unifiedroleassignmentschedulerequest?view=graph-rest-1.0 and https://learn.microsoft.com/en-us/graph/api/resources/unifiedroleeligibilityschedulerequest?view=graph-rest-1.0 — the Graph object shapes, scheduleInfo.expiration and ticketInfo fields used in the Entra ID sample records and raw snippets
   • https://docs.aws.amazon.com/singlesignon/latest/userguide/howtosessionduration.html — permission-set session duration defaults (1 hour) and the 12-hour maximum
   • https://docs.aws.amazon.com/IAM/latest/UserGuide/cloudtrail-integration.html — confirms AssumeRole is the logged event and that the credential expiration timestamp sits inside responseElements, not as a separate expiry event
   • https://www.okta.com/products/privileged-access/ — confirms Okta Privileged Access is a distinct, separately licensed product and that its JIT grants are described as time-bound and auto-expiring
   • https://top10proactive.owasp.org/archive/2024/the-top-10/c1-accesscontrol/ — the OWASP Proactive Controls section naming just-in-time, just-enough access as a least-privilege control
2. Community / current research:
   • https://aws.amazon.com/blogs/security/implementing-just-in-time-privileged-access-to-aws-with-microsoft-entra-and-aws-iam-identity-center/ — AWS's own write-up confirming the approval workflow in this pairing comes from Entra PIM, not from IAM Identity Center itself
   • https://endpointweekly.com/blog/entra-pim-license-expiry-deletes-eligible-assignments.html (2026-07-28) — a practitioner write-up on a related failure mode: a lapsed Entra ID P2 license silently removes PIM-eligible role assignments while leaving standing, permanent admin assignments in the same tenant untouched, the kind of silent breakage this idea's approach is meant to catch before an incident does