Skip to main content

Identity Security

The Identity Security module maps the identity layer of your attack surface — a dimension that conventional vulnerability scanners miss entirely. It connects to your identity providers, inventories every user, service account, and privileged group, computes individual risk scores, and surfaces attack paths that adversaries use to escalate privileges through your organization.

Why Identity Is the New Perimeter​

The traditional security perimeter — firewall, DMZ, network segmentation — is no longer the primary attack surface in enterprise environments. When your employees use SaaS applications, work remotely, and authenticate through cloud identity providers, the identity layer becomes the boundary that attackers target. According to breach data, over 80% of successful compromises involve stolen or misused credentials. Phishing for credentials, abusing over-permissioned service accounts, and exploiting weak MFA policies are significantly more common attack vectors than exploiting unpatched CVEs.

Despite this, most organizations have much better visibility into their CVE inventory than their identity risk inventory. They know which servers are missing patches; they do not know which admin accounts have not logged in for six months, which service accounts have domain admin rights, or which users can reach a critical database server via three escalation steps through nested group memberships.

ThreatWeaver's Identity Security module closes this gap. It answers:

  • Which user accounts are your highest-risk identities right now?
  • Which accounts, if compromised, provide the shortest path to your most critical systems?
  • Where are your over-permissioned accounts, dormant admin accounts, and MFA gaps?
  • How would an attacker move from a compromised low-privilege account to domain administrator?

The module's most differentiating capability — connecting identity risk to vulnerability data — is described at the end of this page under "Integration with Exposure Management."

Architecture Overview​

All identity data is processed within your ThreatWeaver instance. Synced identity records are stored in your tenant's PostgreSQL schema. ThreatWeaver does not transmit identity data to any external service.

Supported Identity Providers​

Azure Active Directory / Entra ID​

The most common enterprise IdP. ThreatWeaver connects using Microsoft Graph API with Application permissions (no user interaction required for sync).

Data synced:

  • All users: display name, UPN, email, enabled/disabled status, created date, last sign-in date, account type
  • Group memberships and nested group resolution
  • Assigned Azure roles (Global Admin, Privileged Role Admin, Security Admin, etc.)
  • MFA registration status per user
  • Conditional Access policies and whether they apply to specific users
  • Service principals (application identities) and their role assignments
  • Privileged Identity Management (PIM) eligible and active role assignments

Risk-relevant fields computed from sync:

  • Days since last sign-in
  • Whether admin-level users have MFA registered
  • Whether Conditional Access policies enforce MFA for admin accounts
  • Service principals with high-privilege roles

Okta​

ThreatWeaver connects to Okta using a read-only API token with the okta.users.read and okta.groups.read scopes.

Data synced:

  • All users and their profile attributes (name, email, department, title)
  • Active, staged, deprovisioned, and suspended user statuses
  • Group memberships
  • MFA factor enrollment (type and enrollment date per factor)
  • Application assignments (which applications each user can access)
  • Password policy assignments

Risk-relevant fields computed from sync:

  • Users with no MFA factors enrolled
  • Users with access to high-value applications but no MFA
  • Deprovisioned users who still have active app sessions (via API observation)
  • Account age vs. last login delta (stale account detection)

Google Workspace​

ThreatWeaver connects using a Google Service Account with domain-wide delegation and the Admin SDK Directory API.

Data synced:

  • All users in the domain: name, email, org unit, created date, last login date
  • Admin status (super admin, delegated admin, specific admin roles)
  • 2-Step Verification enrollment status per user
  • Group memberships
  • OAuth application grants (which third-party apps users have authorized)
  • Suspended and archived user status

Risk-relevant fields computed from sync:

  • Super admin accounts without 2-Step Verification enforced
  • Admin accounts inactive for more than 30 days
  • OAuth grants to non-organizational apps for admin accounts

Active Directory (On-Premises)​

ThreatWeaver syncs from on-premises AD using either:

  • LDAP over TLS — direct LDAP query using a service account with read-only directory access
  • AD Connector Agent — a lightweight agent deployed inside your network that forwards data to ThreatWeaver without requiring inbound firewall rules

Data synced:

  • All user objects: sAMAccountName, UPN, displayName, enabled/disabled, password last set, last logon, department, title
  • Group memberships (including nested group resolution — important for computing effective privileges)
  • Service Principal Names (SPNs) — critical for Kerberoasting detection
  • Computer objects and their operating system versions
  • GPO assignments and settings relevant to security policy (password policy, audit policy)
  • Trust relationships to other domains

Risk-relevant fields computed from sync:

  • Accounts with passwords that have never expired (if password policy exemption is set)
  • Service accounts with SPNs (Kerberoasting candidates)
  • Accounts with DONT_REQUIRE_PREAUTH flag (AS-REP Roasting candidates)
  • Accounts with AllExtendedRights or WriteDACL permissions on domain objects (DCSync path)
  • Users in Domain Admins, Enterprise Admins, or Schema Admins groups
On-Premises AD Network Requirement

ThreatWeaver's backend must have network connectivity to your AD domain controller (ports 389/636 for LDAP, or the agent's outbound port if using the connector agent). For cloud-hosted ThreatWeaver (Render), this typically requires a site-to-site VPN or the connector agent deployment. For on-premises ThreatWeaver deployments, direct LDAP is available if the backend is in the same network.

Identity Explorer​

The Identity Explorer (/identity/explorer) is the searchable, filterable inventory of all identities across all connected providers.

Identity Table Columns​

ColumnDescription
Display NameFull name of the user or service account
Email / UPNPrimary email address or User Principal Name
SourceIdentity provider (Azure AD, Okta, Google Workspace, AD)
Account TypeUser, Admin, Service Account, Shared
Risk Score0-100 identity risk score (see Risk Scoring section)
Risk LevelCritical / High / Medium / Low
MFA StatusEnrolled / Not Enrolled / Exempt
Last LoginMost recent authentication event
StatusActive / Disabled / Deprovisioned
Privilege LevelNone / Standard / Elevated / Admin / Super Admin

Filtering the Explorer​

Analysts typically use the Explorer to answer specific questions:

QuestionFilter to Use
"Which admin accounts have no MFA?"Account Type = Admin, MFA Status = Not Enrolled
"Which accounts haven't logged in for 90+ days but are still active?"Status = Active, Last Login = more than 90 days ago
"Which service accounts have elevated privileges?"Account Type = Service Account, Privilege Level = Elevated or Admin
"Which accounts are at Critical risk level?"Risk Level = Critical
"Show me all identities synced from Okta"Source = Okta

Identity Detail View​

Clicking any identity opens the detail panel:

  • Profile — Full attribute set from the source identity provider
  • Risk Factors — The specific conditions driving the risk score (e.g., "Admin account, No MFA enrolled, Last login 145 days ago")
  • Group Memberships — Direct and nested group memberships
  • Attack Path Involvement — Attack paths that this identity participates in (as source or intermediate step)
  • Sync History — When this identity was last synchronized

Identity Risk Scoring​

Every identity receives a risk score from 0 to 100. Scores are computed during the sync process using a weighted factor model.

Risk Factors​

FactorBase Score ContributionNotes
Admin or Super Admin account+30Elevated privilege is the highest single risk factor
No MFA enrolled+25For admin accounts: +35 (overrides the base)
Account inactive for 30-90 days+15Stale account with maintained access
Account inactive for 90+ days+25Significant stale account risk
Password not changed in 180+ days+10For AD accounts with password never-expires flag
Service account with admin-level permissions+20Service accounts are harder to monitor for compromise
Shared account (multiple users)+15Shared credentials prevent audit trail
Account in attack path (any)+15Participation in a detected attack path
Account in critical attack path (DCSync, Golden Ticket)+25High-severity attack path participation
Active Conditional Access bypass+10Azure AD: CA policy excludes this account
SPN registered (Kerberoasting candidate)+20AD service accounts only
DONT_REQUIRE_PREAUTH flag set+20AD accounts only

Scores are capped at 100. Multiple factors stack additively up to the cap.

Risk Levels​

Score RangeRisk LevelTypical Meaning
75-100CriticalAdmin accounts without MFA, DCSync-capable accounts, service accounts with domain admin rights
50-74HighStale admin accounts, users with SPNs, accounts in detected attack paths
25-49MediumMFA not enrolled on standard users, accounts inactive 30-90 days
0-24LowActive users with MFA and recent login, no elevated privileges

Exposure Categories​

The Exposures page (/identity/exposures) groups identity risks into categories. Rather than scrolling through hundreds of individual accounts, analysts see the exposure landscape at a glance and drill in by category.

Stale Admin Accounts​

What it is: Administrator-level accounts where the last successful login is more than 60 days ago (configurable threshold).

Why it matters: Stale admin accounts are a prime target for attackers. Legitimate admins are unlikely to notice unusual activity on an account they haven't used in months. These accounts often retain full privileges long after the person has changed roles or left the organization.

Example finding: john.doe@company.com — Azure AD Global Admin — last sign-in 134 days ago. Still enabled, no MFA.

Service Accounts Without MFA​

What it is: Non-human accounts (service accounts) with interactive login capability and elevated permissions, but no MFA enrolled.

Why it matters: Service accounts are frequently over-permissioned ("give it admin rights so it works") and under-monitored. A compromised service account credential gives an attacker persistent access that looks legitimate in logs.

What to do: For service accounts that do not need interactive login, disable interactive login entirely. For those that need it, either enroll them in MFA or restrict them to machine-based authentication (managed identity, workload identity).

Over-Privileged Users​

What it is: Standard user accounts (not administrators) that have been granted elevated permissions beyond what their role requires. Detected by comparing the user's job title/department against the permissions and groups they hold.

Why it matters: Excessive permissions violate least-privilege and expand the blast radius of an account compromise. A sales rep with contribute permissions on engineering repositories provides an attacker with access that should not be reachable via that role.

Detection method: ThreatWeaver flags users who hold high-privilege groups or roles while their account type is not classified as Admin — indicating permission drift beyond the standard role.

Shared Credentials​

What it is: Accounts used by more than one person, identified by naming patterns (e.g., admin@, ops@, team-shared@) and by multiple simultaneous geographic sign-in events from the same account.

Why it matters: Shared credentials make audit trails useless. When an incident occurs, you cannot determine which person's actions caused it. Shared accounts are also commonly left with weak, unchanging passwords.

Dormant High-Privilege Accounts​

What it is: High-privilege accounts that have been inactive for 90+ days but remain enabled and fully permissioned.

Why it matters: These are accounts that provide no ongoing business value but maintain full attack surface. They represent accumulated privilege debt — admin accounts from former employees, service accounts from decommissioned integrations, test admin accounts never cleaned up.

Recommended action: Review and disable immediately. If the account was for a specific purpose, verify the purpose is still active. If not, disable the account and document the action.

Accounts Without MFA (Standard Users)​

What it is: Standard (non-admin) user accounts with no MFA factor enrolled.

Why it matters: Password-only authentication is vulnerable to phishing, credential stuffing, and password spray attacks. While the risk is lower than admin accounts without MFA, it is still a meaningful exposure, particularly for accounts with access to sensitive applications.

Attack Path Analysis​

Attack path analysis is the most advanced capability in the Identity Security module. It maps the chains of permissions and trust relationships that an attacker could traverse — starting from a compromised low-privilege account and ending at a high-value target.

See Attack Path Analysis for the full deep dive. Here is a summary of the detected attack path types:

Detected Attack Path Types​

Path TypeSourceDescription
KerberoastingActive DirectoryService accounts with SPNs can have their Kerberos tickets requested by any domain user, then cracked offline. A successful crack yields the service account's plaintext password.
AS-REP RoastingActive DirectoryAccounts with Kerberos pre-authentication disabled allow ticket requests without knowing the password. The returned ticket is encrypted with the account's password hash and crackable offline.
DCSyncActive DirectoryAccounts with DS-Replication-Get-Changes and DS-Replication-Get-Changes-All permissions can replicate all domain credentials from the domain controller — effectively dumping the entire Active Directory password database.
Golden TicketActive DirectoryAccounts with the ability to modify the KRBTGT account's password can forge Kerberos tickets with arbitrary lifetimes and privileges, enabling persistent domain-wide access.
Pass-the-HashActive DirectoryNTLM hashes obtained from compromised machines can be used to authenticate as the victim account without knowing the plaintext password. Particularly dangerous when admin accounts share credentials across machines.
Lateral Movement via Shared CredentialsAll providersWhen multiple systems use the same service account credential, compromise of one system provides access to all connected systems.
Privilege Escalation via Nested GroupsAD, Azure ADDeeply nested group memberships can grant users high privileges indirectly. An attacker compromising account A (in group X) may inherit admin rights through group X → group Y → Administrators chain.

Attack Path UI​

Each attack path shows:

  • Path Name — Human-readable name (e.g., "Kerberoasting via IT Service Account")
  • Risk Rating — Critical / High / Medium
  • Affected Count — Number of identities in this path
  • Step-by-Step Chain — The sequence of accounts, groups, and permissions traversed
  • Entry Points — Where an attacker would start (which accounts to compromise)
  • Target — What the attacker gains at the end of the path (Domain Admin, data access, etc.)

Setting Up Azure AD / Entra ID Connector​

Prerequisites​

  • Azure tenant with Global Administrator or Application Administrator permissions to create App Registrations
  • ThreatWeaver admin access in the Identity Security module

Step 1: Create an App Registration​

  1. Open Azure Portal → Azure Active Directory → App Registrations → New Registration
  2. Name: ThreatWeaverIdentitySync
  3. Supported account types: Single tenant
  4. Click Register
  5. Note the Application (client) ID and Directory (tenant) ID

Step 2: Create a Client Secret​

  1. In the App Registration → Certificates & Secrets → Client Secrets → New client secret
  2. Description: ThreatWeaver Identity Sync
  3. Expires: 12 months (calendar a rotation reminder)
  4. Click Add and copy the secret value immediately

Step 3: Grant Microsoft Graph API Permissions​

The Identity Security module requires these Application permissions (not Delegated):

PermissionPurpose
User.Read.AllRead all user accounts and profile data
Group.Read.AllRead all groups and group memberships
Directory.Read.AllRead directory objects including roles, service principals, and org settings
AuditLog.Read.AllRead sign-in logs for last login detection
Policy.Read.AllRead Conditional Access policies
RoleManagement.Read.DirectoryRead Entra ID role assignments
PrivilegedAccess.Read.AzureADRead PIM (Privileged Identity Management) role assignments

To add these:

  1. In the App Registration → API Permissions → Add a permission → Microsoft Graph → Application permissions
  2. Search for and add each permission above
  3. Click Grant admin consent for [Your Organization] — a Global Admin must approve this step
Admin Consent Required

Without admin consent, the app registration cannot read user data even with the permissions listed. The person granting consent must be a Global Administrator in the Azure tenant.

Step 4: Configure the Connector in ThreatWeaver​

  1. Identity Security → Configuration → Add Connector → Entra ID / Azure AD
  2. Enter:
    • Connector Name: e.g., "Azure AD Production"
    • Tenant ID: Directory (tenant) ID from Step 1
    • Client ID: Application (client) ID from Step 1
    • Client Secret: Secret value from Step 2
    • Sync Schedule: Every 24 hours is typical; every 6 hours for dynamic environments
  3. Click Test Connection
  4. Save and trigger the first sync

Setting Up Okta Connector​

Prerequisites​

  • Okta admin access (Read-Only Admin role is sufficient)
  • ThreatWeaver admin access in the Identity Security module

Step 1: Create a Read-Only API Token in Okta​

  1. In the Okta Admin Console, navigate to Security → API → Tokens
  2. Click Create Token
  3. Token Name: ThreatWeaver Identity Sync
  4. Click Create Token and copy the token value — it is shown only once
Token Permissions

The API token inherits the permissions of the admin account used to create it. Create the token while logged in as a Read-Only Administrator to ensure ThreatWeaver cannot perform write operations through this token.

Step 2: Get Your Okta Domain​

Your Okta domain is the base URL of your Okta tenant, in the format https://your-org.okta.com or https://your-org.oktapreview.com (for preview/sandbox tenants).

Step 3: Configure the Connector in ThreatWeaver​

  1. Identity Security → Configuration → Add Connector → Okta
  2. Enter:
    • Connector Name: e.g., "Okta Production"
    • Okta Domain: Your organization's Okta URL (e.g., https://company.okta.com)
    • API Token: Token from Step 1
    • Sync Schedule: Every 24 hours
  3. Click Test Connection — ThreatWeaver will call /api/v1/users?limit=1 to verify access
  4. Save and trigger the first sync

What Gets Synced from Okta​

ThreatWeaver reads the following Okta API endpoints:

  • GET /api/v1/users — all user records
  • GET /api/v1/groups — all groups and memberships
  • GET /api/v1/users/{id}/factors — MFA factor enrollment per user
  • GET /api/v1/users/{id}/appLinks — application assignments per user
  • GET /api/v1/policies — password and sign-on policies

Integration with Exposure Management​

This is ThreatWeaver's key differentiator in the identity space: connecting identity risk to asset vulnerability data.

The Core Value Proposition​

Traditional CSPM and identity tools operate in silos. A vulnerability scanner tells you: "This EC2 instance is missing a critical patch." An identity tool tells you: "This service account has domain admin rights and no MFA." Neither tool tells you: "The service account with domain admin rights and no MFA is the account used by the application running on the critically vulnerable EC2 instance."

ThreatWeaver connects these dots.

How the Integration Works​

  1. When ThreatWeaver syncs identity data, it looks for linkages between identities and assets in the exposure management inventory. Linkages are detected through:

    • User accounts whose email/UPN matches an SSH key or cloud IAM principal associated with an asset
    • Service accounts whose name matches a database connection string or application credential in a scanned asset
    • Admin accounts whose privilege level indicates access to critical-risk asset groups (Crown Jewel assets)

  2. When a linkage is established, ThreatWeaver creates an Identity-Asset Risk Record that surfaces in the main dashboard. Example:

    svc-payments@company.com (Identity Risk: 82/Critical) has Admin access to payments-db.prod.internal (Asset Criticality: 5 Crown Jewel, 3 open Critical CVEs)

  3. The combined record appears in the main exposure dashboard as an enriched vulnerability item, with both the asset's WeaverScore and the linked identity's risk score visible together.

Why This Matters for Sales​

When demonstrating to a CISO or VP of Security, this is the conversation you want to have:

"Every vulnerability management tool will tell you which CVEs to patch. ThreatWeaver is the only platform that tells you: among all your high-risk vulnerabilities, these five involve assets that are also directly reachable via over-privileged service accounts with no MFA — meaning an attacker who phishes one credentials email could walk straight to your crown jewels without ever touching a CVE."

This is the intersection of identity risk and vulnerability risk. No other tool in the market correlates these two signals at the asset level with a unified score.

Connector Sync Schedule and Freshness​

ProviderRecommended Sync FrequencyWhy
Azure AD / Entra IDEvery 6 hoursHigh change velocity in enterprise tenants; PIM activations are time-limited
OktaEvery 12 hoursUser provisioning/deprovisioning happens frequently in Okta-heavy orgs
Google WorkspaceEvery 24 hoursLower change velocity; Google API quotas are tighter
Active DirectoryEvery 6 hoursGroup membership changes are immediate in AD but LDAP queries are expensive

Module Limitations​

LimitationDetail
No real-time directory monitoringIdentity data reflects the state at the last sync. A user elevated to domain admin at 2pm will not appear in ThreatWeaver until the next sync cycle. For near-real-time updates, reduce the sync frequency to every 1-2 hours.
No password auditThreatWeaver does not check password strength, test for breached credentials (Have I Been Pwned), or evaluate historical password changes beyond the last-change date. Password auditing requires a dedicated PAM or password health tool.
No real-time enforcementThreatWeaver cannot revoke permissions, disable accounts, or enforce MFA. All remediation actions must be taken in the source identity provider. ThreatWeaver provides the visibility to know what to fix; the fix must happen elsewhere.
No PAM integrationPrivileged Access Management tools (CyberArk, BeyondTrust, HashiCorp Vault) are not integrated. Privileged credentials managed by PAM systems are not visible to ThreatWeaver.
No password vaultThreatWeaver does not store, manage, or rotate credentials. It is a read-only analytics layer on top of identity data.
Attack paths are predefinedThe seven attack path types (Kerberoasting, DCSync, Golden Ticket, Pass-the-Hash, AS-REP Roasting, Shared Credentials, Nested Groups) are the supported detection patterns. Custom attack path definitions or novel escalation chains not fitting these patterns are not detected.
Conditional Access Policy analysis is limitedFor Azure AD, ThreatWeaver inventories Conditional Access policies and checks whether admin accounts are covered, but does not perform deep policy logic analysis (e.g., does not evaluate complex conditions or named location filters).
No SaaS application permission analysisThreatWeaver syncs which applications a user is assigned in Okta/Azure AD, but does not analyze the permission level within those applications (e.g., does not know that a user is a Salesforce System Administrator vs. standard user).
On-premises AD requires network accessFor direct LDAP sync, the ThreatWeaver backend must reach the domain controller. For cloud-hosted ThreatWeaver, a VPN or the connector agent is required.