Identity Access - Severity 30 Records
Identity Access Records are SpyCloud's highest-fidelity exposure tier. Each record connects a known identity to stolen session details, so you can identify the victim and reveal the active access an attacker can use. Every Identity Access Record carries the Access severity label, Severity 30.
Where Access sits on the severity scale
Severity 30 is enumerated and displayed alongside the existing SpyCloud severities. Access sits at the top of the scale.
| Severity | Label |
|---|---|
| 2 | Email Only |
| 5 | Informational |
| 20 | High |
| 25 | Critical |
| 30 | Access |
Access records behave like any other severity in the product. They are returned in searches, displayed in the user interfaces, and supported by severity filtering across the APIs, so you can isolate Severity 30 records specifically.
How identity is attached
An Access record is created only when the pipeline can bind a specific identity to a session-theft context. Identity is established through one of four methods. All four produce Severity 30 records.
| # | Method | How identity is established |
|---|---|---|
| 1 | Correlated credential + cookie | A phishing credential and a separate stolen cookie trace to the same incident and are fused into one identity-bound session record. Tags indicate the access granted, such as device code or email access. |
| 2 | Email in the cookie filename | The cookie cannot be decoded, but the filename carries the victim's email, which is enough to bind identity to each stolen cookie. |
| 3 | Identity decoded from the cookie | The cookie is a JWT or base64 blob. Decoding it reveals the email and name inside the asset. |
| 4 | Cookie-theft log context | A credential drawn from a message that is itself a stolen-cookie log, recognized as Severity 30 from context, even with no cookie attached. |
Attack vectors and MITRE mapping
Session theft occurs through the attack patterns below. Most occur after a legitimate login, which is why they evade strong authentication. The mitre_tags field on a record maps to these techniques.
| Attack pattern | When | How the session is taken |
|---|---|---|
| Adversary-in-the-middle relay | At login | A reverse proxy sits between user and IdP, relays the real login and MFA, then captures the issued session cookie. This is the one vector a strong key closes. |
| Infostealer malware | After login | Malware reads session cookies and tokens straight from browser storage on disk. No phishing, no login page, no MFA prompt; HttpOnly does not stop it. |
| Device code phishing | After login | Abuses the OAuth 2.0 device authorization grant (RFC 8628) on the provider's own infrastructure. The victim approves a real prompt; no fake site is involved. |
| OAuth consent phishing | After login | An illicit consent grant: the user authorizes a malicious app, which receives its own refresh token independent of the user's password or MFA. |
| Refresh token / PRT theft | After login | The opaque refresh token, or a Primary Refresh Token cookie on an Entra-joined device, is lifted and replayed to mint fresh access at will. |
Example of Common MITRE ATT&CK techniques referenced in mitre_tags:
| Technique | Name |
|---|---|
| T1557 | Adversary-in-the-Middle |
| T1621 | Multi-Factor Authentication Request Generation |
| T1078 | Valid Accounts |
| T1111 | Multi-Factor Authentication Interception |
Filtering for Access records
Severity filtering supports Severity 30 in addition to the other severities, so you can isolate Access records specifically.
How Access records surface by product
Access records are delivered through your existing SpyCloud entitlements and surfaces. There is no separate install for the record type, and it is included across SpyCloud products without new packaging.
Investigations (Console and API)
The Investigations Console search interface includes Access (Sev 30) as a filter selection. Matching Severity 30 records are returned in query results the same way Sev. 25 or Sev. 20 records are. Investigators can see which applications had active sessions stolen and verify details such as cookie name and expiration, which supports building a broader list of identities that access a specific application, and enriches pattern-of-life analysis for an identity.
The Investigation, CAP, and Service Provider APIs return Severity 30 Access records whenever a search matches them, with severity filtering support for Severity 30.
Workforce Threat Protection / EAP
When an Access record can be connected to a user matching the corporate email domain, it is included in the corporate records shown in All Records and Recent Records views, marked as Access. Selecting a record displays the additional session, MFA, and device code information.
If a single phish or malware event produced multiple sessions, each session is listed as its own Severity 30 record. If the same event also captured credentials, PII, or financial data, that data may additionally appear as a Sev. 5, Sev. 20, or Sev. 25 record depending on the data.
The EAP API returns Severity 30 records for integration into automated workflows. On detecting an Access record, teams should treat it as a likely compromise event and update response playbooks to reset active sessions.
Endpoint Threat Protection / Compass
When an Access record originating from a malware infection can be connected to a watchlist (by corporate or target domain), it appears in the device and application lists the same way Severity 25 records do. The Compass API returns Severity 30 records for automated workflows.
Session Identity Protection (SIP)
SIP provides the ability to search for cookies by domain and cookie name and returns the raw cookie details, supporting two use cases: retrieving an application's stolen cookies so they can be reset, and querying available cookies for a domain to build a set of users who access a specific application. SIP now responds to phishing cookies in addition to malware cookies, and surfaces additional detail about each cookie.
DarkWeb Monitoring API (Pull and Push) / Vela
Applications that leverage DWM receive indications that a user has experienced a stolen Access event, such as a session cookie or refresh token.
IDLink
IDLink automatically incorporates Severity 30 records into its analysis. The new records can be returned to further define the darknet data connected to a holistic identity.
Relationship to Session Identity Protection (Sev 26 cookies)
SpyCloud already delivers cookies through Severity 26, primarily from malware. Access records are highly dependent on cookies but are distinct from the Severity 26 cookie datastore.
- Every cookie or token identified for ingest is included as a Severity 26 cookie. This includes session cookies and tokens, but also marketing and tracking cookies. Session cookies are estimated to represent a small fraction of the total cookie set.
- Only cookies or tokens that can be verified as sessions are ingested as Severity 30. When this occurs, the Severity 30 record includes an asset that can be used to look up the related Severity 26 cookie record.
- Some Severity 30 records indicate a session was stolen even when the full cookie is not available. In those cases there is no associated Severity 26 record.
Remediation
An Access record indicates a session for that identity has likely been stolen. The correct remediation is session revocation, which is different from a password reset. A password reset alone does not close a session an attacker has already stolen.
Enterprise compromised-user playbook
When you detect an employee who has experienced theft of an Access record from a phishing or malware event, execute your compromised-user playbook:
- Reset all sessions within your IdP / SSO.
- Reset all sessions in the application managed by your enterprise. This can sometimes be done with a Universal Session Reset in your SSO.
- Because email compromise is a frequent target, verify whether the stolen sessions (target domain) provide access to email services. If so, verify all MFA processes and forwarding rules for unexpected changes.
- Investigate the account's logs for suspicious behavior.
- Review every application's login and recovery configuration for unexpected values.
- If a Severity 20 or Severity 25 record was also detected, verify whether any company passwords were stolen and remediate them within your IdP.
- Continue to monitor related accounts for further indications of compromise.
Application provider playbook
When an application provider detects a recent Access record for one of its consumers (through evaluation of the target domain):
- Reset all sessions and refresh tokens for that user.
- Review recent changes for that user, such as MFA configuration, large transactions, or backup email and phone configuration.
- Consider that user to be at an elevated risk posture.
Automated remediation with Session GuardianThe presence of an Access record is an indicator that a phish or malware event occurred. This can trigger a configured Session Guardian to reset sessions at the SSO with a Universal Session Reset. If you do not use Session Guardian, use automation or manual analysis to evaluate the target domain of the stolen access and treat the event as a likely compromise.
Coverage note
Coverage depends on what is recaptured. A record is created only when identity can be attached to a session-theft context. Not all exposed credentials have an associated session, and the absence of a Severity 30 record does not mean there is no risk.
Updated about 1 hour ago