Identity security after sign-in: five checks for your next application review

A successful MFA challenge answers an authentication question. It does not tell me whether the user still needs access next month, whether an administrator has too much privilege, or whether a compromised application session can be stopped.

When I review an application’s identity controls, I want to follow access from the initial request through everyday use to removal. The useful output is a small set of evidence: who approved access, what permissions were granted, how privilege is activated, and what happens when access must end.

These are the five checks I would start with.

1. Can we explain why access still exists?

Choose one critical application and identify its business owner. Then trace how a user receives access: direct assignment, group membership, an access package, an application role, or a local application account.

For a hybrid environment, include the on-premises groups and synchronisation dependencies that influence that decision. Removing one cloud assignment may leave another access path intact.

I would ask the owner to review a sample containing a recent joiner, someone who changed role, a guest and a leaver. For each identity, record:

• The business reason for access and the person accountable for approving it.
• The permissions actually available inside the application.
• The event that should trigger a review or removal.
• The evidence that removal reaches the application, including locally held permissions.

A group membership export is useful input. The review is complete only when somebody can explain whether that membership is still appropriate.

2. Does administrative access expire when the task ends?

Microsoft Entra Privileged Identity Management supports time-based and approval-based role activation. I would review each administrative task against the role, scope and activation duration it actually needs.

For example, a routine support task should have a documented role requirement. If the operator is activating Global Administrator, ask which operation requires that breadth and whether a narrower role can perform it.

Check the eligible and active assignments, activation requirements, approver coverage and audit trail. Keep Microsoft Entra roles, Azure resource roles and application-specific administrator roles in view: configuring PIM for one does not automatically govern all three.

In a controlled test, confirm that the intended operation succeeds after activation. Then confirm what happens after expiry, allowing for the target service’s propagation and session behaviour. A successful activation record alone does not prove the complete permission lifecycle.

See PIM: eligibility, approval and the audit trail for the implementation discussion.

3. Can we stop an existing session?

This is where I would turn an incident-response assumption into an application test.

Use a dedicated test identity and an agreed window. Establish an application session, perform the approved containment action, then attempt a fresh protected operation. Capture the action time, client, application response and time at which access stops. Keep cached content separate from a successful new server request.

Microsoft documents that Continuous Access Evaluation depends on support in both the client and the service. An application’s own session cookie also needs consideration; revoking Entra sessions does not establish that every application session has ended.

Record the expected enforcement behaviour for each client and workload instead of promising one universal revocation time. If the application retains its own session, identify the application-side invalidation procedure and its owner.

My session revocation and CAE troubleshooting guide covers the token and cookie distinctions in more detail.

4. Who owns the identities that never see an MFA prompt?

Applications, scripts and services need an identity review too. Start with the workload’s owner, permissions, credentials, sign-in activity and retirement process.

Where the platform supports it, evaluate managed identities or workload identity federation to reduce the need to distribute stored credentials. Permissions and ownership still need review even when there is no password to rotate.

Do not assume a policy targeting human users also protects service principals. Microsoft documents separate Conditional Access capabilities and licensing for workload identities, and managed identities are outside the scope of those Conditional Access policies.

For each workload, I would capture:

• A named owner and the system or process it supports.
• The resource permissions and why each is necessary.
• Its authentication method and any credential expiry dependency.
• The response procedure if the identity or its host is compromised.

Use application consent and permissions and application credential expiry as follow-up checks.

5. Can the team recover administrative access?

Emergency access belongs in the same review as restrictive policies. The team needs a recovery route when its normal authentication or administrative process is unavailable.

Microsoft recommends two cloud-only emergency access accounts permanently assigned Global Administrator. Their protection, monitoring and operating procedures need deliberate design; routine administrator accounts are not a substitute.

Confirm who can use the recovery credentials, how use is detected, when the procedure was last exercised and what is checked afterwards. Avoid a recovery design that depends entirely on the service or device path it is supposed to recover from.

The emergency access account guide provides the detailed considerations.

A review record you can use

Keep the first pass bounded to one application. This is the evidence I would bring to its owner and the identity team.

Area	Evidence to retain	Question to resolve
Continued access	Approval, assignment path and review decision	Does this identity still need these permissions?
Privilege	Role scope, activation settings and expiry test	Does authority match the task and end as expected?
Session containment	Timestamped test and application response	How do we stop new protected operations?
Workload identity	Owner, permissions and authentication method	Who responds if this workload is compromised?
Recovery	Controlled exercise record and alert evidence	Can authorised administrators recover access?

Give each unresolved item an owner and a next action. Agree the remediation order from the application’s business impact and the exposure shown by the evidence.

I would rather finish this exercise for one critical application than collect another tenant-wide checklist with no application owner attached. The aim is to make the access lifecycle explainable, testable and maintainable.

Microsoft documentation

Technical references checked for this article on 2 November 2026:

• Privileged Identity Management overview
• Continuous Access Evaluation
• Revoke user access in an emergency
• Conditional Access for workload identities
• Microsoft Entra security best practices