When attackers use valid accounts, tokens or service credentials, their activity can resemble legitimate access. IT administrators and security teams need to know which human and non-human identities exist, what each can access, how access changes over time and how suspicious use will be contained.
Identity security is the practice of governing, authenticating, authorizing, monitoring and retiring identities so access is limited to the right entity, resource, context and duration. It combines lifecycle governance, privileged access controls, session protection, device context and response processes rather than relying on sign-in security alone.
Key Takeaways
- Identity security protects human and non-human identities throughout their lifecycle, from creation and authentication to access removal and retirement.
- Core controls include IAM, IGA, PAM, MFA, session protection, secrets management, and identity threat detection and response (ITDR).
- Identity security assessments help identify stale accounts, excessive privileges, MFA gaps, unowned service accounts, and unnecessary access.
- Lifecycle security ensures access is reviewed and updated as users change roles, leave organizations, or integrations are retired.
- Device-aware access adds endpoint compliance and contextual signals to access decisions. Scalefusion OneIdP supports this through conditional access policies for integrated applications.
What is identity security, and why does it matter?
Identity security applies controls across an identity lifecycle: creation, authentication, access assignment, change, monitoring and retirement. It helps teams answer:
- Who or what is requesting access?
- How was that identity verified?
- What can it access, and why?
- Does the current context justify access?
- How will access be detected, restricted or withdrawn if it is misused?
Identity and access management (IAM) provides foundational capabilities for managing identities and controlling access. Identity security builds on these capabilities and related controls to address risks involving excessive privileges, compromised credentials, stolen sessions, non-human identities and suspicious activity throughout the access lifecycle.
No single control covers the full access lifecycle. Multi-factor authentication (MFA) strengthens sign-in, governance helps keep permissions current, session controls protect ongoing access, and monitoring supports containment when suspicious use occurs. CISA’s IAM guidance similarly treats MFA, least privilege, session protection and monitoring as complementary practices.
Which identities and threats does it cover?
An identity security program should cover every identity that can access an organizational resource, including identities that do not represent an individual person.
Workforce, customer and non-human identities
Workforce identities belong to employees, contractors, temporary workers and partners. Their access should reflect their role, employment status and work requirements.
Customer identities access customer-facing applications and services. They may use different enrollment, recovery and privacy processes, but their sessions and permissions still require protection.
Privileged identities can administer directories, cloud environments, endpoints, applications, databases or security controls. They usually require stronger authentication, tighter monitoring and shorter access duration than standard accounts.
Non-human identities include service accounts, application and workload identities, API keys, certificates and integration credentials. Each needs a documented purpose, accountable owner, constrained permissions, credential-management process and retirement plan.
Credential theft, stale access, token misuse and privilege abuse
Common identity risks include:
- Credential theft: Passwords or other authentication material are obtained through phishing, malware, password reuse or another compromise.
- Stale accounts: Employee, contractor or service accounts remain enabled after their legitimate use ends.
- Stale grants: An active identity retains permissions from an old role, project or group.
- Session or token theft: A valid browser cookie, access token or refresh token is used after authentication has occurred.
- Privilege abuse: An authorized or compromised identity uses elevated access outside its intended purpose.
- Unowned non-human access: A service account or integration credential remains active without accountable ownership.
NIST SP 800-63B-4 notes that cookies commonly track authenticated sessions and that access or refresh tokens can remain valid after the original authentication session ends. Authentication, session management and token revocation are therefore related but distinct controls.
How do identity security controls work together?
Different control categories address different parts of the access lifecycle. Deploying one does not remove the need for the others.
IAM, IGA, PAM and secrets management: distinct responsibilities
| Control area | Primary responsibility | Key question |
|---|---|---|
| Identity and access management (IAM) | Identity records, authentication, federation and access enforcement | Who is the identity, and how can it sign in? |
| Identity governance and administration (IGA) | Provisioning, approvals, entitlement reviews and deprovisioning | Why does it have access, who approved it and is it still needed? |
| Privileged access management (PAM) | Control and oversight of elevated access | Who can perform privileged actions, under what conditions and for how long? |
| Secrets management | Storage, distribution and rotation of machine credentials | How are application credentials protected and replaced? |
Centralized sign-in does not prove permissions are current. Rotating a service credential does not prove that the service account still has a valid owner. Recording privileged activity does not remove unnecessary administrator membership.
Authentication, Zero Trust, ITDR and posture checks
Authentication verifies an identity at sign-in. MFA is an important protection, but it should be paired with session protection and access monitoring.
A Zero Trust approach evaluates access to a resource instead of assuming trust because a request comes from a corporate network or company-owned device. NIST SP 800-207 describes subject and device authentication and authorization as discrete functions before access to an enterprise resource is established. Relevant signals can include identity, device status, resource sensitivity and request context.
For this guide, identity threat detection and response (ITDR) refers to the detection-and-response work around suspicious identity activity. Teams should monitor and alert on events such as unexpected privilege changes, abnormal sign-in patterns or unusual service-account use. This detection layer does not replace preventive controls; it supports investigation and containment when an identity may already be misused. CISA recommends monitoring and alerting for suspicious IAM activity as part of broader access protection.
Device posture checks provide another access signal by determining whether an endpoint meets configured requirements. They do not independently establish that the user, session or application is safe.
Where should an identity security assessment start?
Start with visibility. Teams cannot reliably secure accounts, permissions or credentials they have not identified.
Inventory identity stores, privileged accounts and service accounts
Map systems that create, store or authenticate identities, including:
- Authoritative workforce directories and cloud identity providers
- On-premises directories and SaaS application accounts
- Local administrator and application accounts
- Cloud roles and privileged groups
- Service accounts, workload identities and application registrations
- API keys, certificates and integration credentials
- Emergency or break-glass accounts
For high-risk and non-human identities, record the owner, purpose, authentication method, permissions, dependencies, last known activity and retirement process. Microsoft’s account security posture guidance identifies stale accounts, stale service accounts and unnecessarily privileged service accounts as conditions requiring attention.
Do not apply one inactivity threshold to every account type. A dormant contractor account and an infrequently used emergency account have different purposes and risks. Define thresholds by account type, then verify dependencies before disabling or deleting an identity.
Check MFA exceptions, unowned access and stale grants
Review identity objects and their permissions. Prioritize findings such as:
- Interactive accounts without MFA
- MFA exceptions without an owner, expiry date or compensating control
- Former employee or contractor accounts that remain enabled
- Permissions retained after a role or project change
- Permanent administrative access where temporary elevation would be sufficient
- Service accounts without a named owner or documented purpose
- Local application accounts outside centralized authentication
- Shared or embedded credentials without a replacement process
- Integrations that remain active after the supporting business process ends
An exception may be necessary, but it should not be invisible or permanent by default. Record who approved it, why it exists, how it is monitored and when it will be reviewed.
Record owners, remediation priorities and coverage measures
Every finding needs an accountable owner and a target action. Prioritize remediation using privilege level, resource sensitivity, exposure, identity type, evidence of activity and ease of containment.
Useful measures include:
- Percentage of eligible interactive accounts covered by MFA
- Number and age of MFA exceptions
- Number of unowned privileged and service accounts
- Number of stale accounts and stale entitlements
- Percentage of scheduled access reviews completed on time
- Time required to disable an account and revoke supported active sessions after suspected misuse
- Percentage of high-risk applications covered by centralized authentication and access policies
These are coverage and operating-discipline measures, not proof of security. High MFA coverage does not show whether sessions can be stolen. Completed reviews do not prove that reviewers made correct decisions. Containment time does not prove every compromised token was identified.
How should access change across an identity’s lifecycle?
Access should change when a person changes roles, a contract expires, an application is replaced or a machine identity is no longer needed.
An employee or contractor joiner–mover–leaver example
Consider a contractor joining a six-month infrastructure project.
- Joiner: A sponsoring manager requests access linked to a contract end date. The contractor receives a unique account, required authentication methods and only the groups and applications needed for the project. Administrative access is issued separately for approved tasks.
- Mover: If the contractor moves from infrastructure support to documentation, old cloud roles and administrative groups are removed while new access is assigned.
- Leaver: At contract end, sign-in is blocked, supported active sessions and applicable tokens are revoked, privileged access is removed, and devices or credentials are recovered. Data ownership and scheduled jobs are transferred before account deletion under organizational policy.
The mover stage is a common lifecycle failure point: teams add new access but do not remove old access. Role changes should trigger both provisioning and removal checks.
A service account ownership, credential and retirement example
A service account needs a lifecycle even though it has no employment record. When an integration is created, document:
- The application or process it supports
- A named business or technical owner
- Required systems and permissions
- The credential or authentication mechanism and where it is stored
- How credentials will be replaced or rotated
- Dependencies to check before suspension
- Conditions for retirement
Review the account when its owner changes, the application is upgraded or the integration’s purpose changes. When the integration ends, disable the identity during a controlled window, monitor for dependency failures, remove permissions and credentials, then delete or archive the account according to policy.
Rotating a secret is not retirement; it leaves the identity and its permissions in place.
How can teams detect and respond to identity misuse?
Monitoring should connect recognizable attack patterns to prevention, detection and containment. Responders need to know which sessions, credentials and dependencies may need to be revoked.
Map common attacks to controls, warning signs and residual risks
| Scenario | Preventive controls | Warning signs | Residual risk |
|---|---|---|---|
| Stolen password | MFA, credential protection, authentication policy | Unusual sign-in source, repeated failures, unexpected recovery activity | Malware or phishing may still capture other authentication or session material |
| Stolen session cookie or token | Secure session handling, contextual access, suitable session exposure limits | Session use from unexpected contexts or activity inconsistent with the user | A valid token may appear legitimate until detected or revoked |
| Stale account misuse | Timely deprovisioning, inactivity review, ownership records | Sign-in to a dormant account or activity after a contract ends | Legitimate but infrequent accounts can be misclassified |
| Privilege abuse | Least privilege, separate admin identities, temporary elevation, monitoring | Unexpected role assignment or unusual administrative actions | Authorized access can still be misused |
| Service credential compromise | Constrained permissions, protected secret storage, credential replacement | Use from an unexpected workload, unusual API activity or configuration changes | Rotation can disrupt dependencies or fail to invalidate active tokens |
Relevant monitoring sources include authentication, directory, application, endpoint and cloud-control-plane events.
Triage and contain suspicious account or token activity
A password reset may not be sufficient. Responders should first determine what was compromised and what access remains active.
- Validate the signal. Identify the user or workload, affected resources, event times, source context and observed actions.
- Assess privilege and scope. Check group membership, cloud roles, delegated access, application grants, active sessions and linked service credentials.
- Contain current access. Restrict sign-in where appropriate, revoke active sessions and tokens supported by affected systems, and disable compromised credentials.
- Protect administrative paths. Remove unauthorized privilege changes and check recovery methods, federation settings and application credentials for alteration.
- Investigate endpoints and applications. Determine whether malware, browser compromise or a malicious application could reacquire credentials or tokens.
- Restore access safely. Reissue authentication material and return the identity to service only after the cause is addressed.
- Preserve evidence and improve controls. Retain relevant logs and update detection, lifecycle or access policies based on the failure.
The containment action must match the credential type. Resetting a password may not invalidate every cookie, access token, refresh token or application secret. Available revocation actions depend on the affected identity provider and applications.
Where does device-aware access fit?
Device-aware access adds endpoint condition to an identity decision. It helps determine whether a valid identity is requesting access from a managed device that meets defined requirements.
Conditional access and device-based SSO with Scalefusion OneIdP
Scalefusion OneIdP combines identity and access management with device context from Scalefusion UEM. It supports single sign-on (SSO) and conditional access policies that use device compliance and contextual signals to control access to integrated applications.
Scalefusion’s Extended Access Policies (XAP) documentation describes access conditions such as device compliance, operating system updates and patches, IP address, location and application presence. Scalefusion evaluates configured conditions and passes a compliance signal to OneIdP, which can allow or block access to SSO-integrated services.
Available conditions depend on the device platform and configured Scalefusion services. IT administrators should verify the relevant prerequisites and platform support before applying these policies.
For example, an administrator can require a high-value work application to be accessed from a Scalefusion-managed device that meets defined compliance requirements. For SSO-integrated services configured with Extended Access Policies, Scalefusion also documents automatic logout when a device becomes noncompliant. However, this should not be interpreted as universal revocation of every application session or token.
This behavior depends on the relevant OneIdP setup, SSO integration, user groups, device-management configuration and compliance policies. Beyond device-aware access, OneIdP supports identity and access management through SSO, MFA, identity lifecycle management and selected privileged access controls. Broader requirements such as enterprise-wide identity discovery, non-human identity governance, secrets management and identity threat detection and response should be assessed separately.
Device security policies as a complementary endpoint control
Conditional access determines whether a request should reach an application. Endpoint security policies address the device condition itself, including configuration, updates, applications and other device settings.
The controls reinforce each other but are not interchangeable. A compliant device does not prove a session token is legitimate, and valid user authentication does not prove the endpoint is appropriately managed. Identity, device, session and resource signals should be evaluated according to the sensitivity of the requested access.
FAQs
1. Can MFA prevent attacks involving stolen session cookies?
Not necessarily. MFA strengthens the sign-in event, but an attacker who obtains an already valid session cookie or token may be able to act as the authenticated user without repeating MFA. Secure session handling, contextual access checks, monitoring, reauthentication where appropriate, token revocation and incident containment are also needed. The UK National Cyber Security Centre notes that reauthentication can reduce the useful life of stolen session credentials but cautions against relying on frequent, fixed-interval prompts. Reauthentication should be used when additional assurance is needed, alongside contextual access checks, session monitoring and other protective controls.
2. Who should own service accounts and integration credentials?
Each service account or integration credential should have a named business or technical owner accountable for its purpose and continued use. Record its permissions, dependencies, credential-management process and retirement path. Review it periodically and remove it through a controlled process when the integration ends.
3. Does single sign-on eliminate identity sprawl?
No. SSO centralizes authentication for integrated applications, but it does not automatically discover unmanaged accounts, remove local application access, correct stale permissions or assign owners to non-human identities. Teams still need identity inventory, governance, access reviews and deprovisioning processes.
4. How can a team tell whether its identity controls are working?
Track MFA coverage and exceptions, unowned or stale accounts, stale entitlements, access-review completion and the time needed to contain suspected misuse. Interpret each measure carefully: coverage does not prove effectiveness, completed reviews do not prove correct decisions, and fast containment does not prove that every compromised session or token was found.
Strengthen identity security across the access lifecycle
Effective identity security requires coordinated controls across authentication, access governance, privileged access and incident response. Regular assessments help IT and security teams identify unnecessary access, address security gaps and maintain appropriate permissions as identities change.
Scalefusion OneIdP supports these efforts through SSO, MFA, device-aware access policies, identity lifecycle management and selected privileged access controls.
Manage identity and device-aware access with Scalefusion OneIdP.