-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ
Frequently asked questions about the first public release.
The PowerShell module is the original tool and remains the right answer for power users, automation, and CI / CD. The portal exists for the people on your team who don't want to install PowerShell, manage modules, or troubleshoot WAM brokers — and for the moments when you're on a borrowed machine, on mobile, or just want a click-through. Both projects share the same activation model and policy handling.
Yes, with the same caveat that applies to any browser-based tool: the portal trusts the browser session it runs in. Tokens are held in sessionStorage only and disappear when you close the tab. Every privileged call goes directly from your browser to Microsoft. There is no backend, no proxy, no telemetry. See Security and Privacy for the full breakdown including the Content Security Policy and threat model.
No. There is no server-side anything. Tokens live in sessionStorage and are cleared when the tab closes. The portal also persists no tokens to localStorage, IndexedDB, or cookies.
No. The Content Security Policy enforces this — the only network destinations the portal can talk to are login.microsoftonline.com, graph.microsoft.com, management.azure.com, and cdn.jsdelivr.net (for the MSAL.js bundle).
Yes. The portal is responsive and works in mobile Safari, mobile Chrome, mobile Edge, and Firefox for Android. Some MFA / Conditional Access flows are easier on desktop, but bulk activation works fine on a phone.
No. Every privileged call goes to Microsoft. The portal needs a network connection to do anything useful.
Yes. Use the tenant switcher in the header to switch directories. Your eligibilities in that tenant — Entra roles, Azure Resource roles, and PIM Groups — appear as if you were signed in there directly.
An administrator can pre-consent the application using the standard /adminconsent endpoint:
https://login.microsoftonline.com/<your-tenant>/adminconsent?client_id=<portal-app-id>
For the managed portal, the application ID is the multi-tenant app published to portal.pimactivation.com. For self-hosted deployments, use the adminConsentUrl output emitted by the Bicep deployment.
That is the Conditional Access auth-context step-up flow. A role's policy requires you to satisfy a stronger authentication (typically MFA or a compliant device claim) before activation. The portal threads the resulting claims into every subsequent request in the operation, so you only see the prompt once per step-up requirement.
In your browser's IndexedDB. They survive across sessions on the same browser profile, but they are not synchronized across devices and they don't leave the browser.
Not in the first release — there is no built-in import / export. It's on the Roadmap. For now, ask your teammate to recreate the profile in their own browser.
If you have Tenant-scoped profiles enabled in Settings, profiles only appear when you're signed in to the matching tenant. Disable the setting to see all profiles regardless of tenant.
See Self-Hosted Deployment. There is a one-click Deploy to Azure button in the README and a full Bicep template you can az deployment group create against directly.
The default SKU is Free for Azure Static Web Apps. The other resources created (a managed identity, a small storage account for source caching) cost a few cents per month at most. Choose the Standard SKU if you need custom domain SSL with private endpoints, deployment-staging environments, or higher quotas.
Today the portal does not expose a branding configuration surface — to change the favicon, name, or theme palette you need to edit the source. PRs welcome.
Yes. Each deployment is bound to its own app registration. Just create a separate app registration for each and pass its client ID to the Bicep template.
- Activation history sourced from the Entra audit log surface (only in-session activity history is shown today)
- Profile import / export
- Polling for approval-required role state changes (you must refresh manually)
- Cross-device profile sync (profiles are per-browser-profile)
- Localization / right-to-left layouts
- Built-in scheduling beyond a future start time
See Roadmap for what's planned.
- A backend, a proxy, or any server-side component
- Application permissions or any client secret in the SPA
- Persisting tokens outside
sessionStorage - Telemetry, analytics, or any third-party API call beyond the Microsoft endpoints listed above