Series A funding puts full identity lifecycle security in focus

At a glance

What this is: WideField Security’s Series A spotlights full identity lifecycle security, with a focus on protecting human, machine, and AI identities after authentication.

Why it matters: It matters because IAM, NHI, and PAM teams increasingly need visibility into sessions, tokens, privileges, and third-party access, not just sign-in events.

By the numbers:

• WideField Security raised $11.3 million in Series A funding led by Crosspoint Capital Partners.
• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them.

👉 Read WideField Security's Series A announcement on full identity lifecycle security

Context

Identity security often stops at authentication, but the control gap usually opens after the login succeeds. Once a session is active, tokens, privileges, third-party access, and machine identities can be abused without the visibility that many IAM programmes are designed to provide.

WideField Security’s funding announcement is really a signal about programme scope. Enterprises are being pushed toward lifecycle-wide identity governance that spans human IAM, NHI controls, and AI identity exposure, because attackers increasingly operate in the space between sign-in and session closure.

For teams trying to close that gap, the issue is not simply more authentication. It is whether the organisation can see, govern, and revoke access across the full identity lifecycle, including the parts that traditional reviews and MFA checkpoints do not cover.

Key questions

Q: How should security teams reduce risk when authentication is no longer the main attack boundary?

A: Security teams should move from sign-in-centric controls to lifecycle-centric controls. That means monitoring active sessions, limiting token lifetime, separating machine identity governance from human access reviews, and revoking third-party access when business need ends. The goal is to shorten the period in which a trusted identity can be abused after authentication.

Q: Why do machine identities create different governance problems from human accounts?

A: Machine identities often have broad, persistent permissions and no natural user to receive prompts or alerts. That makes them harder to review with human-centric IAM processes and more likely to remain valid long after the original use case changes. Governance must therefore track ownership, expiry, and revocation as lifecycle attributes.

Q: When should organisations prioritise token and session governance over more MFA rollout?

A: Organisations should prioritise token and session governance when they already have MFA coverage but still lack visibility into what happens after authentication. If attackers can reuse active sessions, delegated permissions, or exposed tokens, stronger login controls will not stop post-authentication abuse. The higher-value move is to reduce the lifetime and reach of trusted access.

Q: What is the difference between authentication control and identity lifecycle control?

A: Authentication control decides whether an identity can get in. Identity lifecycle control decides how that identity is created, used, monitored, delegated, and eventually removed. In practice, lifecycle control is what limits the damage after access exists, especially for machine identities, integrations, and vendor tokens that persist across systems.

Technical breakdown

Why post-authentication identity risk matters

Post-authentication risk begins after credentials are accepted, when the session becomes the real control plane. At that point, access tokens, browser sessions, delegated permissions, and service-account credentials can be reused or chained into broader access. This is why identity compromise often persists even when MFA is present. The attacker does not need to defeat login again if the authenticated session already exists. Practical monitoring has to shift from event-based sign-in checks to continuous session and token governance.

Practical implication: extend monitoring and revocation logic beyond authentication events to active sessions, tokens, and delegated access.

How machine identities expand the identity attack surface

Machine identities include service accounts, API keys, workload credentials, and certificates that operate without human interaction. They usually outnumber human identities and are often granted broad, persistent access because they are tied to systems rather than people. That makes them hard to review with human IAM processes. When these identities are not lifecycle-managed, they become durable pathways into cloud, SaaS, and on-premises environments. The key technical issue is not volume alone, but weak ownership and weak revocation discipline.

Practical implication: inventory machine identities separately from human accounts and attach explicit owners, expiry, and revocation workflows.

Why third-party token theft is a lifecycle problem

Third-party token theft is a lifecycle failure because the identity is still valid even after the relationship that created it has changed. OAuth tokens, shared integrations, and vendor access often survive far longer than the business need that justified them. Attackers exploit that persistence by inheriting trust already granted to the integration. Technical controls therefore need to combine scoping, session visibility, and offboarding discipline, not just authentication strength. If the token can still act, the lifecycle is still open.

Practical implication: treat integration tokens as revocable lifecycle objects, not static configuration.

Threat narrative

Attacker objective: The attacker aims to convert trusted identity access into durable reach across multiple systems without triggering the controls that focus only on login.

1. Entry begins when an attacker reaches a valid identity path through stolen OAuth tokens, compromised sessions, or exposed machine credentials.
2. Escalation follows as the attacker reuses trusted access to move from one application or environment into adjacent cloud or SaaS resources.
3. Impact occurs when the compromised identity is used to read, export, or manipulate sensitive data across connected systems.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Authentication-only security is now a broken operating model. The funding points to a structural gap: many programmes still treat login as the security boundary, even though the highest-risk abuse happens after the session is established. That leaves token theft, session hijacking, and delegated access outside the primary control loop. The implication is that identity governance must be measured by what remains controllable after authentication, not by sign-in success rates.

Full identity lifecycle security is becoming the practical bridge between IAM and NHI governance. Human access, service accounts, and AI identities now share the same lifecycle problem: provisioning, use, delegation, monitoring, and offboarding. When those stages are managed separately, blind spots appear exactly where attackers look for durable access. Practitioners should treat lifecycle governance as a cross-identity discipline rather than three disconnected tool categories.

Post-authentication visibility is the new blast-radius control. Once identity compromise is the entry point, the differentiator is whether teams can see which sessions, tokens, and relationships remain active. That changes incident containment, privileged access review, and third-party governance at the same time. The field is moving toward broader identity telemetry because isolated authentication controls no longer describe the true attack surface.

Identity blast radius is the concept this announcement sharpened. The relevant question is no longer whether a user or workload authenticated successfully, but how far a valid identity can move before lifecycle controls intervene. This concept connects IAM, PAM, and NHI governance into one operational view. Practitioners should assess every identity against the scope of damage it can still cause after initial trust is granted.

From our research:

• 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For the operational breakdown behind those numbers, see the NHI Lifecycle Management Guide for provisioning, rotation, and offboarding patterns.

What this signals

Identity programmes are moving from authentication assurance to lifecycle assurance. That shift matters because the control question is no longer whether an identity can sign in, but whether it can still act after the business need changes. Identity blast radius: the amount of damage a trusted identity can still cause after authentication. Teams that cannot measure it will keep mistaking login coverage for real containment.

The NHI lifecycle problem is now inseparable from IAM operations. With 96% of organisations storing secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to our guide to the key challenges and risks, the governance gap is not theoretical. Practitioners should expect more pressure to unify human, machine, and integration access under one revocation model.

The practical next step is to align policy, telemetry, and offboarding around session persistence rather than identity type alone. NIST Cybersecurity Framework 2.0 remains useful here because it forces teams to connect identify, protect, detect, and respond activities across the full lifecycle. If your programme cannot answer who still has usable access after authentication, it is not yet governing the real attack surface.

For practitioners

• Map post-authentication control points Identify where your current stack can observe and revoke access after login, including active sessions, delegated permissions, and long-lived tokens.
• Separate machine identities from human IAM reviews Build a distinct inventory for service accounts, API keys, certificates, and workload credentials, then review ownership, expiry, and revocation independently from human accounts.
• Add third-party token offboarding to lifecycle workflows Require explicit offboarding for vendor-issued tokens and integrations when contracts, permissions, or business need change, so trust does not outlive the relationship.
• Measure identity blast radius continuously Score identities by privilege scope, token persistence, and downstream system reach so incident response can prioritise the accounts that can still cause the most damage.

Key takeaways

• The core problem is post-authentication exposure, where sessions, tokens, and delegated access remain usable after the login event.
• The evidence points to a persistent control gap in NHI governance, especially around offboarding, token revocation, and machine identity visibility.
• Practitioners should measure identity risk by residual blast radius, not by whether authentication controls are deployed.

Key terms

• Post-authentication risk: Post-authentication risk is the exposure that remains after an identity has successfully signed in or been granted access. It includes active sessions, tokens, delegated permissions, and machine credentials that can be reused, hijacked, or abused without defeating the initial login control again.
• Identity blast radius: Identity blast radius is the amount of damage a trusted identity can still cause once access has been granted. It depends on privilege scope, token persistence, third-party reach, and how quickly lifecycle controls can reduce or revoke usable access after compromise.
• Machine identity: A machine identity is a non-human identity used by software, workloads, services, or integrations to authenticate and act. It often includes service accounts, API keys, certificates, or tokens, and it requires lifecycle governance because it can persist long after the original human request is forgotten.
• Lifecycle governance: Lifecycle governance is the discipline of controlling identity from creation through use, review, delegation, and removal. In practice, it determines whether access is still valid, who owns it, and how quickly it can be revoked when the business need, relationship, or threat landscape changes.

What's in the full analysis

WideField Security's full article covers the operational detail this post intentionally leaves for the source:

• The vendor's explanation of how its platform maps identity attributes, privileges, and relationships across cloud, SaaS, and on-premises environments.
• The specific post-authentication threat signals it uses to detect session hijacking and third-party token theft.
• The customer example that shows how visibility into machine identities changed day-one triage.
• The company background and funding context that frame its go-to-market expansion plans.

👉 WideField Security's full announcement covers the funding context, product scope, and customer example in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.