# Privileged user sessions don't have long lived sign-in sessions
When privileged users are allowed to maintain long-lived sign-in sessions without periodic reauthentication, threat actors can gain extended windows of…
Source: https://maester.dev/docs/tests/ZTA.21825
## Overview
When privileged users are allowed to maintain long-lived sign-in sessions without periodic reauthentication, threat actors can gain extended windows of opportunity to exploit compromised credentials or hijack active sessions. Once a privileged account is compromised through techniques like credential theft, phishing, or session fixation, extended session timeouts allow threat actors to maintain persistence within the environment for prolonged periods. With long-lived sessions, threat actors can perform lateral movement across systems, escalate privileges further, and access sensitive resources without triggering another authentication challenge. The extended session duration also increases the window for session hijacking attacks, where threat actors can steal session tokens and impersonate the privileged user. Once a threat actor is established in a privileged session, they can:
- Create backdoor accounts
- Modify security policies
- Access sensitive data
- Establish more persistence mechanisms
The lack of periodic reauthentication requirements means that even if the original compromise is detected, the threat actor might continue operating undetected using the hijacked privileged session until the session naturally expires or the user manually signs out.
## Remediation
- [Learn about Conditional Access adaptive session lifetime policies](https://learn.microsoft.com/entra/identity/conditional-access/concept-session-lifetime?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
- [Configure sign-in frequency for privileged users with Conditional Access policies ](https://learn.microsoft.com/entra/identity/conditional-access/howto-conditional-access-session-lifetime?wt.mc_id=zerotrustrecommendations_automation_content_cnl_csasci)
## Run it
The check runs as part of the whole assessment, with the ZeroTrustAssessment module installed:
```powershell
Install-Module ZeroTrustAssessment -Scope CurrentUser
Connect-Maester
Invoke-Maester -Pack ZTA -SkipBuiltIn
```
Leave out `-SkipBuiltIn` to run Maester's own checks in the same run.
About this check
| | |
| --- | --- |
| Severity | Medium |
| Effort to fix | Low |
| Impact on users | Medium |
| Pillar | Identity |
| Category | Access control |
| Product | [Entra ID](/docs/tests/products/entra) |
| Feature | Conditional Access |
| Area | Privileged access |
| ATT&CK | [T1550.004](/docs/tests?mitre=T1550.004) Web Session Cookie, [T1539](/docs/tests?mitre=T1539) Steal Web Session Cookie |
| Licence | P1 |
| Tenant | Workforce |
Product, feature, area and ATT&CK are Maester's: the assessment does not record them, so Maester keeps them in the pack's `taxonomy.json`.