Home · Solutions · Other solutions
Solution · Other solutionsRequested in Teams, approved, granted for hours, then removed by a schedule
Admin rights that exist only for the task and the hour
Privileged access is requested with a reason and a duration, approved by the system owner, granted by Privileged Identity Management or a robot, and revoked when the clock runs out.
Executive summary
Rights granted for a four-hour task stay for a career, in systems that cannot expire them.
The design splits the estate into what Microsoft already governs and what it does not, because the two halves need different machinery.
The standing admin population shrinks to the roles that have to be permanent, because everything else expires by itself.
Entra and Azure roles through Privileged Identity Management; SQL Server clusters; Linux hosts
Business problem
Privileged access
Privilege is granted for a task and kept for a career. An engineer needs to read a production database during an incident, messages a platform engineer in Teams, and is added to a group, a database role or a subscription. The grant takes four minutes and the intention to remove it afterwards is genuine. Removal is an interruption with no requester behind it, competing with work somebody is waiting for, so later rarely comes.
What accumulates is a population nobody planned. The spreadsheet of standing admins is kept by hand and recertified once a quarter in a meeting that confirms the status quo, because nobody in the room has usage data to challenge it with. Accountability is diffuse: the platform team grants, security worries, and no named owner answers for who holds what.
The gap widens outside the identity platform. Entra and Azure roles can be made eligible rather than permanent. An on-premises SQL Server cluster, a Linux fleet, a network device or the ERP's own user store cannot: each has its own way of granting and none has a way of expiring, so expiry has to be built rather than switched on. Emergency access closes the circle. It runs on shared credentials from a vault whose name everyone knows, which makes the most sensitive actions in the estate the least attributable ones.
How it works today
This is the route a privileged request takes today in most infrastructure teams.
- PersonAn engineer messages one of four platform engineers in Teams: read access to a production database, incident reference, needed now
- PersonThe platform engineer adds the account to the group, the database role or the subscription, then returns to their own work
- Risk of errorNo end time is recorded anywhere, because most of these systems have no field to record one in
- WaitingRemoval waits for somebody to remember it, and the person who asked has no reason to ask again
- SystemThe standing-admin spreadsheet is updated afterwards, from memory, when there is time
- WaitingOnce a quarter, managers recertify that spreadsheet in a meeting held without any data on who used what
- Risk of errorAn auditor samples the privileged groups, finds people who changed team, and raises standing privilege again
Why the current process costs more than it appears
Time that disappears before anyone measures it.
- A right granted for a four-hour task is live for every remaining hour of the year, and nothing in the estate distinguishes the two.
- Blast radius is the sum of everything that was never removed. When one engineer's account is compromised, the incident report lists entitlements that outlived their purpose by months.
- Recertification consumes senior security and engineering time every quarter and changes little, because confirming a list is faster than challenging it without usage evidence.
- Shared break-glass credentials make the most sensitive actions the hardest to attribute, which is the opposite of what an emergency needs afterwards.
- Waiting is a cost as well as a risk. Four platform engineers set the speed at which 220 engineers get access, so urgent work queues behind whoever happens to be free.
Cost of inaction
Rights do not decay. A grant made for a four-hour task is still live at midnight in December, and the sum of everything never removed is what a single compromised engineer account would reach. The table above prices the handling. It cannot price that, which is precisely the part a board asks about after an incident.
Direction matters more than the totals. Engineering headcount grows faster than platform teams, every new system arrives with its own way of granting and none of expiring, and the privileged groups gain members between clean-up projects. A repeat finding on standing privilege is a more serious finding than the first, and by then the clean-up costs more than the control would have.
A plausible organisation with realistic proportions. The figures are there to be recalculated on your data; they are not a client result.
A payments company with 900 employees, 220 of them engineers. Microsoft Entra ID and Microsoft Azure govern the corporate estate; on-premises SQL Server clusters, a Linux fleet, network devices and the ERP's user store sit outside Entra roles entirely.
Around 240 privileged access needs a month: production database reads during incidents, temporary owner rights on a subscription, elevated access on an application server, the occasional network change.
Each need reaches one of four platform engineers as a Teams message. Request, grant, later removal and the spreadsheet entry take about 45 minutes of combined effort, spread over days.
Removal has no owner and no trigger. The quarterly recertification of standing admins costs roughly 60 hours of security and engineering management time and confirms most of what it reviews. The last audit raised standing privilege as a finding.
Entra and Azure roles become eligible rather than permanent under Privileged Identity Management. Everything outside Entra is requested on a card in Microsoft Teams, approved by the named system owner, granted by a robot and revoked by a schedule that reads the end time from a register.
Seven needs in ten handled without a platform engineer, roughly 126 hours a month, and a recertification that becomes a weekly exception list. That share is the assumption worth arguing with; test it against your own request log first.
Proposed solution
The design splits the estate into what Microsoft already governs and what it does not, because the two halves need different machinery. For Entra and Azure roles we configure Privileged Identity Management: engineers become eligible for a role instead of members of it, activation asks for a justification and multifactor authentication, sensitive roles also require an approval, and every role carries a maximum duration. Entra ID Governance access packages cover time-bound application access, and access reviews handle the remainder that has to stay permanent.
For everything Entra does not reach we build the same discipline. A request card in Microsoft Teams asks four questions: which system, which role, why, and for how long within the policy maximum. The system owner or the on-call lead approves there. A robot grants the right in the SQL Server cluster, the Linux host, the network device or the ERP user store through its administration interface and writes the grant, the approver and the end time into a register in UiPath Data Fabric. An Orchestrator time trigger revokes each expired grant and confirms the removal against the target system rather than assuming it worked.
Two paths sit alongside the standard one. Break-glass access is granted immediately, logged in full and queued for a named security person to review the next working day, which keeps emergencies fast without making them anonymous. A weekly report lists every privilege that exists with no open request behind it, which turns recertification from a meeting into an exception list.
Microsoft Entra Privileged Identity Management with eligible assignments, activation on justification and multifactor authentication, approval and a maximum duration; Microsoft Entra ID Governance access packages and access reviews; Microsoft Teams Approvals app; UiPath Orchestrator time triggers, credential store and audit; Microsoft Purview audit log
The Teams request card, the duration and approver policy per system and role, the robots that grant and revoke in the systems Entra does not reach, the register of grants and end times, the revocation schedule with its confirmation step, the break-glass path and the weekly standing-privilege report
Eligibility and group changes through the UiPath Integration Service connector still named "Microsoft Azure Active Directory"; the administration interfaces of the SQL Server clusters, the Linux fleet, the network devices and the ERP user store
How the automated process works
- PersonAn engineer opens the privileged access card in Teams and states the system, the role, the reason and a duration inside the policy maximum
- AutomationEntra and Azure roles route to Privileged Identity Management, where the engineer is eligible and activation asks for a justification and a second factor
- PersonSensitive roles and every system outside Entra go to the named owner, who decides in Teams with the reason in front of them
- AutomationA robot grants the right in the target system and writes the grant, the approver and the end time into the register
- AutomationAn Orchestrator time trigger revokes each grant at its end time and reads the system back to confirm the removal happened
- Risk of errorA failed revocation raises a task for security the same hour instead of being retried quietly
- AutomationBreak-glass requests are granted at once, logged with requester and reason, and queued for next-day review
- SystemA weekly report lists every standing privilege with no open request behind it, per system and per owner
Human-in-the-loop model
Automation handles
- Presenting the request with the maximum duration the policy allows for that system and role
- Granting through Privileged Identity Management in Entra and Azure, and through robots everywhere else
- Recording every grant with its approver and end time in the register
- Revoking at expiry and confirming the removal against the target system
- Producing the weekly report of privilege that remains standing
People decide
- Approval of activations and grants for sensitive roles and for the systems outside Entra
- The durations, approvers and eligible groups for each system, owned by the CISO rather than by the platform team
- The next-working-day review of every break-glass use
- What happens to the standing privileges the weekly report cannot explain
Before and after
Systems and integrations
The stack is deliberately short: one engine, one execution layer, one place where a person decides.
Inputs
- privileged access requests in Microsoft Teams
- incident references from the service desk
- the catalogue of systems and roles with their named owners
- break-glass requests
Automation layer
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service
- UiPath Data Fabric
- UiPath Action Center
Target systems
- Entra and Azure roles through Privileged Identity Management
- SQL Server clusters
- Linux hosts
- network devices
- the ERP user store
Human touchpoints: Microsoft Teams Approvals; Action Center tasks in Teams; the weekly standing-privilege report
Technologies used
makes Entra and Azure roles eligible rather than permanent; activation with justification, multifactor authentication, approval and a maximum duration
Aaccess packages for time-bound application access and access reviews for what stays permanent
Athe request card and the owner's decision, where engineers already work
Agrant and revoke where Entra does not reach; time triggers, queues, credential store, audit trail
Adirectory group and eligibility changes through the Microsoft identity connector
Athe register of grants, approvers, systems and end times
Afailed revocations and unusual requests as tasks completed inside Teams
Aaudit evidence for activations, approvals and administrative actions
AIllustrative economic model
Numbers you can check against your own data.
Fold the automatable share into the volume: of the 240 privileged needs a month, the calculator prices only the 168 that Privileged Identity Management or a robot handles end to end, at 45 minutes of request, grant, removal and spreadsheet work each and €68 an hour fully loaded for an engineer in this illustrative payments company. Recertification sits in the next section rather than in the calculator, licensing and implementation are excluded, and the risk reduction, the real reason to do this, is not priced at all.
Run the numbers on your data
An illustrative estimate from your own inputs. It models released capacity; it is not a promise of savings.
Business benefits
- The standing admin population shrinks to the roles that have to be permanent, because everything else expires by itself
- Access arrives in minutes with a recorded approval, faster than finding a platform engineer who is free
- Removal is executed by a schedule and confirmed against the system, so grants stop accumulating between clean-ups
- Systems outside Entra get the same expiry discipline as the ones inside it, which closes the gap auditors look for first
- Every privileged action is attributable to a person, a reason and a request, emergencies included
- Quarterly recertification becomes a short review of an exception list instead of a 60-hour ritual
The management view
- Standing privilege stops being an opinion and becomes a number that moves week by week, per system and owner
- Ownership is explicit: each system has a named person who sets the durations and approves the grants
- Evidence exists per grant and per removal, so audit sampling stops depending on what someone remembers
- Senior platform people are freed from grant-and-remove chores, and access stops queuing behind their calendars
Board-level KPIs
Security and governance
The automation holds exactly the rights it needs, and not one more.
- The robot's own rights are the most sensitive object here, so each target system gets a dedicated service account limited to role assignment, and every action carries the request that caused it
- Robot credentials sit in an external credential store integrated with Orchestrator, typically Azure Key Vault, and are never shared with a person
- Requesting and approving are separated: an engineer cannot approve their own grant, and the platform team cannot change a maximum duration without a documented decision from security
- Failed revocations are treated as security events and surface the same hour, because a grant that silently outlives its end time is the failure mode that matters most
- Break-glass grants are time-limited, logged and reviewed by a named person the next working day, with approvals corroborated in Microsoft Purview
- Processing stays in the EU regions of UiPath Automation Cloud and Microsoft 365
Why now
Auditors have moved from "show us the policy" to "show us the grant and the removal", and insurance questionnaires now ask about standing privilege directly, which turns housekeeping into a board matter
Eligible roles, activation with approval and time-bound assignments are configuration in Entra ID Governance today, so the Microsoft half of the estate needs no development; the half outside it is what robots cover
The modelled €8,568 a month of engineering capacity is the smaller argument, but it compounds: engineering teams grow faster than platform teams, so the manual route gets slower every quarter
Relevant executive roles
Standing privilege becomes a measured exception with an owner rather than the default state of the estate, and the audit finding gets a route to closure
Engineers get production access in minutes with a record behind it, and senior platform people stop spending weeks on grant-and-remove chores
Privileged access becomes a governed service with a service level, not a favour that depends on who is online
Evidence exists per grant and per removal, across the Microsoft estate and the systems outside it
Common questions and objections
A card with an approval that lands in minutes is less friction than hunting for a platform engineer, and an eligible role activates in seconds without an approver. What disappears is the waiting; what appears is typing a reason.
For Entra and Azure roles it does, and we configure it rather than rebuild it. Standing privilege hides in the database clusters, Linux hosts, network devices and the ERP user store, which have no expiry of their own; that is what the robots and the register cover.
The break-glass path grants immediately and logs everything, so nothing gets slower when it matters. The difference from today is that a named person reviews the use the next morning and the account is not shared.
When this is not the right solution
- The whole estate sits inside Entra and Azure: configure Privileged Identity Management, review it properly, and stop there
- Fewer than a few dozen privileged needs a month and a platform team of two who know every grant they have made
- A privileged access management platform is already deployed and covers the systems outside Entra
- The organisation will not name an owner per system, so the flow has nobody to route a decision to
A question for the next management meeting
Standing privilege is a decision nobody in this company remembers making, so who in this room can name the last administrative right that was removed because the task behind it had finished?
Implementation approach
A scope without ambiguity, before anything is signed.
We deliver
- An inventory of standing privilege across Entra, Azure and the systems outside them, with the last use of each right
- Privileged Identity Management and access package configuration, with a named owner per role
- The duration and approver policy per system and role, agreed with the CISO and written down
- Robots that grant and revoke in each non-Entra system, with handling for the grants that fail
- The register, the revocation schedule, the break-glass path and the weekly report
- Pilot on one Entra role and one outside system, then rollout in order of risk with hypercare
We need from you
- A named owner for each system that will issue privilege, with authority to set durations and approve
- Entra ID P2 or Entra ID Governance licences for the people in scope
- Dedicated administrative accounts for the robots in each target system, scoped to role assignment
- A security review of the maximum durations and of the break-glass path before go-live
Stages
Inventory
Every standing right, where it lives, who holds it and when it was last used
Policy
Maximum durations, approvers and eligible groups per system and role, signed off by security
Build
Request card, robots for grant and revoke, register, revocation schedule, reporting
Pilot
One Entra role and one system outside Entra, with the platform team approving every grant
Rollout
Systems converted in order of risk, then permanent membership trimmed to documented exceptions
Departmental. Effort is driven by the number of systems outside Entra, how each one grants and removes rights, and how quickly an owner can be named for each.
Thirty-one names in the domain admin group, and nine of them did not use it this quarter.
Export the membership of your privileged groups and roles with the date each was granted. We come back with the share a request-and-expire model would replace in the first month and the systems that would need a robot.
Send your privileged group exportThe neighbouring process usually has the same problem
The auditor finds your role conflicts once a year. By then the oldest of them is twelve months old.
View solution Other solutionsApplication access granted by policy in minutes, with proofAccess is granted from interpreted emails, approvals are chased, and the auditor finds the evidence missing.
View solution Other solutionsAccess reviews that reviewers finish, with the removals doneQuarterly access reviews eat weeks of specialist time, get approved by default and remove almost nothing.
View solutionIndustries we deliver this in most oftenManufacturing & industryTransport & logisticsServices & ITShared services