Temporary and Test Account Strategy for Microsoft Entra ID

1. Executive summary

Temporary and test accounts are among the least governed identities in most Microsoft Entra ID tenants. They are created quickly, rarely owned by a named person, and often left enabled long after the work has finished. Attackers look for exactly these accounts, because nobody notices when one of them signs in.

This strategy treats every temporary or test account as a dormant asset. Each account stays disabled until a named owner requests it for a fixed period, with a business reason and, where needed, an approval. When the period ends, the account is disabled again without anyone having to remember. The model mirrors Privileged Identity Management (PIM), which most organisations already use for administrator roles.

Microsoft does not offer this as a single product feature. It is assembled from standard Entra ID components plus a small amount of automation, and it can be delivered in four phases over roughly twelve weeks. Three licensing routes are set out, so the design can be adopted whether the organisation holds Entra ID P1, P2 or Entra ID Governance licences.

2. The problem

A test account exists to prove that something works. Once the test is complete, the account has no purpose, yet it normally remains enabled with a password that someone wrote down. A temporary account for a contractor or a migration behaves the same way. Over several years a tenant accumulates dozens or hundreds of these identities.

The risk has four parts, and each compounds the others:

• No owner. The person who created the account has moved on, so nobody can confirm whether it is still needed.
• Weak credentials. Test accounts are often excluded from Multi-Factor Authentication (MFA) so that testing is convenient, and passwords are shared within a team.
• Standing access. Accounts keep the group memberships, licences and sometimes administrator roles they were given for a single test.
• No detection. Sign-ins from a test account look routine, so misuse is unlikely to raise an alert.

An enabled account that nobody is using is pure exposure with no offsetting benefit. Reducing the time each account is enabled is therefore the single most effective control available.

3. Design principles

4. Target architecture

The recommended design uses Entitlement Management, part of Entra ID Governance, as the request and approval front end. An access package represents “permission to have a test account active”. A custom extension links the access package to an Azure Logic App, which carries out the enablement and disablement through the Microsoft Graph Application Programming Interface (API). Microsoft documents custom extension triggers for when an assignment is granted and when it is removed, which map directly onto activation and expiry [1].

Components

5. Request, enable and expire flow

The request model: owner requests for self

A disabled account cannot sign in to request its own activation, so the request has to come from a person. In the recommended model the owner requests the access package for themselves and names the target account in a request question. The Logic App then confirms that the requester is the recorded owner of that account before it acts.

This model has two practical advantages. Only the human owners need governance licences, not the test accounts. It also avoids making a disabled account the subject of an access request, a scenario that should not be assumed to work without testing.

The trade-off is that an owner holds one assignment per access package at a time. An owner who needs several accounts live together should be able to list more than one account in a single request, and the Logic App should handle a list.

Step by step

1. Request. The owner opens the My Access portal, selects the package, and supplies the account name, the duration and a justification.
2. Approve. Short activations of ordinary test accounts are auto-approved. Longer periods, or accounts with access to sensitive systems, route to an approver.
3. Grant. Entitlement Management creates the assignment and calls the Logic App.
4. Enable. The Logic App checks the tag and the owner, sets accountEnabled to true, creates a single-use TAP, and sends it to the owner over an authenticated channel. It writes a record of the activation.
5. Expire. When the assignment ends, or the owner hands it back early, the Logic App sets accountEnabled to false, revokes sign-in sessions and deletes any remaining TAP.
6. Reconcile. The hourly sweep catches anything the event-driven path missed.

Suggested activation tiers

Each tier is implemented as a separate assignment policy on the access package. Durations are starting points to be tuned to the organisation.

6. Guardrails

Containment

Place every in-scope account in a restricted management administrative unit. Tenant-wide administrators, including User Administrators, then lose the ability to enable the accounts or reset their credentials by hand. Assign the Logic App identity and a small break-fix group the roles they need at the scope of the unit only. The restricted setting must be chosen when the unit is created; it cannot be applied afterwards.

Conditional Access

• Require a compliant device or a trusted network location.
• Set sign-in frequency to a few hours and disable persistent browser sessions.
• Block legacy authentication and block access to administrative portals unless specifically needed.
• Where a test genuinely needs MFA to be absent, grant a named exception to one account for one activation, not a standing exclusion for the group.

Privilege

Temporary and test accounts hold no permanent directory roles or Azure role assignments. Where a test needs privilege, make the account eligible through PIM for Groups, so that privilege requires its own activation with its own time limit. Two independent time limits then apply: one for the account and one for the privilege.

Monitoring

7. Account lifecycle

Creation

Accounts are created through one route only: a request form or service desk item that captures the owner, purpose and end date. The automation creates the account in a disabled state, applies the naming convention (for example tst- and tmp- prefixes), sets the tag, and adds the account to the administrative unit. No password is issued.

Review

Owners confirm each quarter that their accounts are still needed. An access review is the natural mechanism where licensing allows; otherwise a scheduled report to each owner works. Accounts that are not confirmed are scheduled for deletion.

Ownership change

When an owner leaves or changes role, ownership passes to their manager for fourteen days. If nobody claims the account in that period, it is deleted.

Deletion

Deleted users remain recoverable in Entra ID for 30 days, which gives a safety margin for mistakes.

8. Licensing and cost options

The design can be reached by three routes. They differ in how polished the request experience is and how much custom automation the organisation has to own. Microsoft lists custom extensions for Entitlement Management among its Entra ID Governance features [4], so the recommended route needs that licence for the people who make requests.

Route B in brief. Each owner is made eligible for a group that represents their test accounts. Activating the group membership in PIM is the request. A scheduled job reads group membership and enables or disables the matching accounts. The experience is familiar to anyone who already uses PIM, at the cost of a short polling delay.

Route C in brief. The guardrails in section 6 do most of the risk reduction and need only P1. The request and timing logic is entirely custom, so the organisation carries more build and support effort.

9. Phased rollout

Phases 0 and 1 deliver most of the risk reduction and do not depend on the licensing decision. They can begin immediately.

Measures of success

• Percentage of in-scope accounts disabled at any moment (target: above 90%).
• Number of in-scope accounts with no valid owner (target: zero).
• Number of in-scope accounts holding a standing privileged role (target: zero).
• Enablements outside the approved process per month (target: zero).
• Median activation duration, tracked for trend.

10. Risks, assumptions and open decisions

11. Technical annex

The material below is a starting point for the build team. It has not been run against a live tenant and should be validated during the pilot.

11.1 Logic App outline

TRIGGER  Entitlement Management custom extension (HTTP request)
READ     stage, requester object ID, assignment end time, answers (target accounts)

FOR EACH target account
  GET    user: accountEnabled, extensionAttribute10, manager
  CHECK  tag is TESTACCT or TEMPACCT        else reject and alert
  CHECK  manager ID equals requester ID     else reject and alert

  IF stage = assignment granted
    PATCH  user: accountEnabled = true
    POST   temporaryAccessPassMethods: single use, short lifetime
    SEND   pass to requester over authenticated channel
    LOG    account, requester, justification, end time

  IF stage = assignment removed
    PATCH  user: accountEnabled = false
    POST   revokeSignInSessions
    DELETE any remaining temporaryAccessPassMethods
    LOG    account, requester, actual end time

11.2 Permissions for the automation identity

Prefer roles scoped to the administrative unit over tenant-wide application permissions wherever the pilot shows they are sufficient.

11.3 Dynamic group rule

(user.extensionAttribute10 -eq "TESTACCT") or (user.extensionAttribute10 -eq "TEMPACCT")

11.4 Reconciliation sweep logic

active  = target accounts named in current access package assignments
tagged  = users where extensionAttribute10 in (TESTACCT, TEMPACCT)

FOR EACH user in tagged
  IF user.accountEnabled AND user NOT IN active
    disable user, revoke sessions, raise alert "enabled outside process"
  IF user.manager is empty OR manager is disabled
    flag "no valid owner"
  IF end date has passed
    queue for deletion

11.5 Example detection queries (Kusto Query Language)

Enablement by anything other than the automation identity:

AuditLogs
| where OperationName in ("Enable account", "Update user")
| mv-expand prop = TargetResources[0].modifiedProperties
| where prop.displayName == "AccountEnabled" and prop.newValue has "true"
| extend target = tostring(TargetResources[0].userPrincipalName)
| where target startswith "tst-" or target startswith "tmp-"
| extend actor = coalesce(tostring(InitiatedBy.app.displayName),
                          tostring(InitiatedBy.user.userPrincipalName))
| where actor != "<automation identity name>"

Sign-ins by tagged accounts, for comparison against the activation log:

SigninLogs
| where UserPrincipalName startswith "tst-" or UserPrincipalName startswith "tmp-"
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress,
          ResultType, ConditionalAccessStatus

12. Glossary

13. Bibliography

1. Microsoft Learn. Trigger Logic Apps with custom extensions in entitlement management. https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-logic-apps-integration (accessed 07/10/2026).
2. Microsoft Learn. Request access package on-behalf-of other identities. https://learn.microsoft.com/en-us/entra/id-governance/entitlement-management-request-behalf (accessed 07/10/2026).
3. Microsoft Learn. Restricted management administrative units in Microsoft Entra ID. https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/admin-units-restricted-management (accessed 07/10/2026).
4. Microsoft Learn. Microsoft Entra ID Governance licensing fundamentals. https://learn.microsoft.com/en-us/entra/id-governance/licensing-fundamentals (accessed 07/10/2026).