PIM and temporary access
Nobody should hold Global Administrator, or the right to wipe a device, all day every day. Plugboard gives you two ways to hand out that kind of access for an hour instead:
- Microsoft Entra PIM through a flow. A technician asks for one of the admin roles they are eligible for, and turns it on themselves by signing in to Microsoft. Entra’s own policy stays in charge.
- Temporary access. Plugboard’s own sensitive permissions (password resets, local admin passwords, device wipes and the like) in time-limited bundles, approved by someone else. This works on every Microsoft licence and without Entra at all.
Both start from Request access in your account menu.
Entra PIM through flows
Section titled “Entra PIM through flows”The principle: PIM’s policy is the wall, Plugboard is the front door. Plugboard reads your PIM settings, checks eligibility and limits, and records everything. The activation itself is done by the person, as themselves, so Microsoft’s multi-factor check, the role’s authentication context and its approval rules all still apply.
Plugboard never holds a permission that can grant or remove a directory role. Its reads of eligible roles, active roles, role policy and PIM’s audit entries are application-only and read-only. It only activates eligible roles; it does not create eligible assignments and never changes PIM settings.
Request an admin role
Section titled “Request an admin role”The gallery template Request an admin role is a flow the person runs for themselves. They choose:
| Input | Rules |
|---|---|
| Role | One of the roles they are eligible for in Entra |
| For how long (minutes) | 15 to 480 in the template, and never more than the role’s own maximum |
| Reason | At least 10 characters |
The flow then has three steps:
- Activate the admin role. The run shows an Activate button to the
person who asked (and only them). It opens a Microsoft sign-in as
themselves, then returns to
/pim/callbackand back to the run. - Wait until the role ends.
- Check the role has ended. It reads their active roles. If the role is still on, the step fails and says so.
Before the sign-in starts, Plugboard refuses if their Plugboard account is not linked to a Microsoft account, if they are not eligible for the role, if the reason or duration do not fit, or if they have asked for that role three times today or ten times this week. Those last two send them to the ICT lead.
The sign-in is single use, expires after 10 minutes, and is bound to that run step, that person and that browser session. The Microsoft account they sign in with must be the one linked to them; signing in as anyone else is refused and audited. The access token is used for that one activation and is never stored, logged or audited. If nobody signs in within a day, the step gives up.
If the role needs approval in PIM, the run shows “Asked for the role; waiting for approval in Microsoft Entra”. Role approvers decide in Entra, not in Plugboard. When the run has a case ticket, its number is sent to PIM with the request.
An admin role can only be requested by the person themselves. It takes no go-ahead, and another app can never request one (see external flows and hooks).
Set it up first
Section titled “Set it up first”Admin, Temporary access (/admin/elevation), section Before admin
role requests can run. The admin role steps stay unavailable in the builder
until every item passes, and Request access tells anyone who asks for an
admin role that requests are not set up yet. Reading the checklist needs identity.policy.view;
running it and confirming consent also need connector.manage.
| Item | How it passes |
|---|---|
| Microsoft Entra ID P2 or Microsoft 365 A5 | PIM answers. A3 and A1 do not include it. Connect Microsoft Entra ID first |
| The desk address is set | PUBLIC_URL is set on the server. Add <PUBLIC_URL>/pim/callback as a redirect address on the school’s app registration |
| Admin consent for RoleAssignmentSchedule.ReadWrite.Directory | You add that delegated permission to the app registration, grant admin consent, and press I have granted admin consent. It also passes once any role has been activated through Plugboard |
| Approval is on for every privileged role | PIM requires approval for Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator and Intune Administrator |
Run the check from that section whenever something changes. Each check is stored and audited.
Below it, Privileged access in Microsoft Entra lists what Plugboard found in your PIM settings and what to fix: roles with no approval or no approver named, no multi-factor check, more than two hours, permanent holders who should be eligible instead, and PIM groups that are not role-assignable. Without Entra ID P2 this section says so; temporary access still works.
PIM-managed groups are never changed
Section titled “PIM-managed groups are never changed”A flow step or a desk action that adds or removes group members refuses a
group that PIM manages: make people eligible in PIM instead. If Plugboard
cannot check whether a group is PIM-managed, the group stays read-only until
the app registration is granted
PrivilegedEligibilitySchedule.Read.AzureADGroup. Without Entra ID P2 there
is no PIM to bypass, so the change goes ahead.
Global Administrator alerts
Section titled “Global Administrator alerts”Whenever someone activates Global Administrator through Plugboard, or asks
Entra for it, a sticky alert goes to everyone who holds
identity.policy.view, naming who, for how long, and why, with a link to the
run. The same moment is also a flow trigger, Someone activates Global
Administrator, if you want to do more (see
schedules and calling flows).
Temporary access
Section titled “Temporary access”Admin, Temporary access. Managing bundles needs role.manage.
Bundles
Section titled “Bundles”A bundle is a set of sensitive permissions people can ask for, for a while. Each bundle has:
| Field | What it does |
|---|---|
| Name and What it is for | People see these when they ask |
| Permissions | From the sensitive permissions, such as resetting passwords and MFA, managing and re-enabling accounts, mailbox Full Access, reading local admin passwords, and requesting or approving device wipes. You can only add permissions you hold |
| Longest someone can have it | Up to 8 hours |
| Ask for a reason | At least 10 characters, read by the approver. On by default |
| Ask for the ticket it is for | The ticket is checked against the asker’s own access |
| Who can ask | Holders of these roles, and these people |
| Who approves | Named roles and people. Never the person asking |
Saving a bundle needs step-up.
What can never be elevated
Section titled “What can never be elevated”A bundle can never hold role.manage, user.manage, site.manage,
flow.publish, integration.manage or every permission (*). Each of these
lets a person give out access, so a temporary grant could extend itself. They
are refused when a bundle is saved and filtered out again on every request.
See permissions.
Asking
Section titled “Asking”Open your account menu and choose Request access, then Plugboard access. Pick the bundle, how long, why, and the ticket if the bundle asks for one. Sending the request asks you to confirm it is you (step-up).
You can have one open request or grant per bundle. A request is refused when nobody else could approve it, so name a second approver on every bundle.
The same dialog’s An admin role choice starts the Request an admin role flow for you.
Approving
Section titled “Approving”Approvers see waiting requests under Access requests to decide in their account menu and under Waiting for you on the Temporary access page. No email or alert is sent.
To approve, you must be named on the bundle, not be the person asking, and hold
every permission in the bundle through your own roles (or hold role.manage).
Approving needs step-up. Anyone named can decline. If two approvers press at
once, only the first counts.
While it lasts
Section titled “While it lasts”The access is checked on every request you make. It stops on your first request after it ends; there is nothing to wait for.
A countdown sits in the header (in the account menu on a phone), showing the minutes left, with End now to give it back early. An approver can end it too. Asking, approving, declining, ending and every bundle change are recorded in the audit log.
Access held all the time
Section titled “Access held all the time”Access held all the time shows, for each sensitive permission, how many people hold it through their role. Make them eligible instead opens a bundle already filled with that permission and those people. Save it, then take the permission out of their role on the Roles page.
Temporary access and flows
Section titled “Temporary access and flows”Temporary access never counts toward a flow’s go-ahead. Whether someone may give a go-ahead is worked out from their roles alone, so a grant you hold for an hour does not let you approve account changes in a flow. Batch go-aheads never include admin role runs, and nothing about temporary access can start a flow: each grant is approved by a person, with step-up, every time.
On the public demo, temporary access works, but Activate the admin role is unavailable.
Related
Section titled “Related”- People flows
- Flows overview, for go-aheads and risk tiers
- Microsoft Entra ID
- Directory accounts