Dashboard
Security overview
A live view of privilege use, pending decisions, and recent access across your estate.
Request outcomes
Privilege demand
What needs attention
Privilege requests
Select a row to read the complete decision and endpoint trail.
| Expand | Who | What | Requested | Admin window | State | Decision | Actions |
|---|---|---|---|---|---|---|---|
| Loading activity… | |||||||
Estate
Managed devices
Agent health, applied policy, certificate status, and last contact in one view.
Endpoint estate
Certificates expiring within 30 days are highlighted for review.
| Device | State | Agent | Windows | Policy | Certificate expires | Last seen |
|---|---|---|---|---|---|---|
| Loading devices… | ||||||
Governance
Access policy
Decide what happens when somebody asks for administrator rights. Saving switches the new version on; devices pick it up at their next check-in.
1The request
When somebody asks for administrator rights on their own device
2The window
How long do the rights last?
Windows closes on its own; nobody has to remember to take the rights away.
3The reason
Do they have to say why?
Optional
Exceptions for individual programs
Only for requests to run one program as administrator. The first matching line wins; anything that matches nothing falls through to the setting above.
| Applies to | What happens | For how long | Remove |
|---|
Nothing here yet. Every request for a single program follows the setting above; add a line to treat one differently.
Earlier versions
Versions are never edited or deleted. To go back, activate an older one.
| Version | What it does | Created | |
|---|---|---|---|
| Loading… | |||
Advanced: edit the policy document directly
Everything the forms above produce, plus anything they do not cover. Validated on save.
Evidence
Audit trail
A plain-language, append-only record of every decision and elevated action. Select any line to open the full record.
Recorded events
Use the filters to answer a specific audit question; raw records remain available for technical review.
Loading audit trail…
Deployment
Windows agent
The piece that runs on each computer. Try it on one machine, then hand the same package to Intune for the rest.
How are you putting it on devices?
Settings written into every install
The download already carries these. They are here because an Intune package built by hand needs them spelled out, and because the agent pins the policy key at enrolment and refuses a policy signed by anything else.
All files on the server
| File | Size | Added | SHA-256 |
|---|
Desktop app
Branding
Your name, colours and logo on the app people see on their computer. Leave a field empty to keep the built-in look.
Only an administrator can change the branding. You can look, and download the files.
Name and support line
Logo
It replaces the shield in the app's header.
A PNG, square, up to 512 × 512 pixels and 96 KB. Transparent works best: it sits on the header colour.
Colours
Usually the accent is all you need. Every colour is checked for readability against the one behind it, the same way the app does.
Shape and timing
Administration
Settings
Everything this deployment runs on, in one place. Each section is checked against the running server, so nothing here is ever out of date.
What to paste into Entra when you register this portal, and a test that it reaches Microsoft.
In the Entra admin center: App registrations → New registration, name it EPM Admin Portal, single tenant. Then paste these four values into it.
One row per Entra directory. Adding or disabling one takes effect at once, with no restart.
One row per Entra directory. Adding or disabling one takes effect at once, with no restart.
| Name | Directory (tenant) ID | Sign-in | State |
|---|
Add another directory
Register the same EPM Admin Portal application in the other directory, with the redirect URI above and the same three app roles, then paste its ids here.
People
Everybody this portal knows. What somebody may do comes from Entra; what they are told comes from here.
Somebody who signs in with Microsoft is added the first time they visit. Add them before that to have them told about requests from the start.
| Name | Signs in with | Role | Told about | Last seen |
|---|
Roles for a Microsoft sign-in come from Entra, so they are shown here but not edited here. Editing somebody changes what they are told, never what they may do.
Your own password and security keys. Nobody else can change these for you.
For a service desk with no Entra, and the account this portal was handed over with.
A password here has no Conditional Access and no MFA in front of it. Add a security key to any account that keeps one.
Notifications
How approvers find out that somebody is waiting. A request nobody sees is a request that expires.
Where messages go. Email reaches each approver; a Teams card reaches everybody who can see the channel.
| Channel | Sends | State | Last delivery |
|---|
What went out lately, and what did not. Kept for 30 days.
| When | Event | To | State |
|---|
Devices authenticate with a certificate, not a password. This server issues them.
Devices authenticate with a certificate, not a password. This server issues them, after Microsoft Entra confirms the device is yours.
In the Entra admin center, on the same app registration: API permissions → Add a permission → Microsoft Graph → Application permissions → Device.Read.All, then Grant admin consent. That is what lets the server check a device before it signs its certificate.
Authority that signs device certificates
| Subject | Kind | Expires | Fingerprint |
|---|
What each device needs
Where agents connect, and what they need to get in.
Nothing appears under Devices or in the audit trail until at least one agent has checked in.
Where the agents connect
App roles, the Entra checklist and what this server is running. Read once, then forgotten.
App roles to create
| Display name | Value | Grants |
|---|