TL;DR: Agentic AI and embedded copilots are expanding SaaS attack surfaces through persistent OAuth connections and overly permissive integrations, according to Obsidian Security. The governance gap is no longer just access scope, but whether identity controls can see and contain non-human actors operating inside business apps.

NHIMG editorial — based on content published by Obsidian Security: Leading SaaS security platform strengthens executive bench as the company scales toward growth funding

By the numbers:

• Obsidian Security protects more than 200 organizations across North America, Europe, the Middle East, Southeast Asia, Australia, and New Zealand.

Questions worth separating out

Q: How should security teams govern SaaS integrations that use persistent OAuth tokens?

A: They should treat persistent OAuth grants as identity objects with owners, purposes, and revocation paths.

Q: Why do AI agents increase risk in SaaS environments?

A: AI agents increase risk because they can operate through existing application permissions and continue using them as tasks change.

Q: What do teams get wrong about OAuth security in business apps?

A: Teams often focus on the token and miss the relationship behind it.

Practitioner guidance

• Inventory persistent SaaS delegations Build a complete register of OAuth grants, app-to-app links, and embedded copilots, then assign each one to a business owner and a renewal date.
• Separate AI-enabled workflows from standard automation Tag workflows that can initiate actions inside SaaS tools without direct human approval, and treat them as non-human identity pathways with explicit control boundaries.
• Review token behaviour and app relationships together Correlate token usage with workload context, in-app activity, and the expected relationship between the application and the data it touches.

What's in the full analysis

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

• Leadership expansion details and the operating assumptions behind scaling a SaaS security programme
• How the vendor connects application sprawl, embedded copilots, and AI agents to broader SaaS risk
• The role of its Knowledge Graph in correlating SaaS, endpoint, network, and identity data
• Company context on growth readiness and the market narrative around securing SaaS in the era of agentic AI

👉 Read Obsidian Security's analysis of agentic AI risk in SaaS security →

Agentic AI and SaaS security: are OAuth controls keeping up?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: The Xfinity breach used credential stuffing and an OTP bypass to take over customer accounts, add recovery email addresses, and extend access into other services, according to Axiad. Passwordless and stronger authentication reduce exposure, but account recovery and cross-service reuse remain the real control gaps.

NHIMG editorial — based on content published by Axiad: Xfinity Data Breach: How It Happened (and Are You Affected?)

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: What breaks when 2FA is bypassed through account recovery abuse?

A: 2FA breaks as a containment control when attackers can reset trust through recovery workflows.

Q: Why do credential stuffing attacks still succeed against consumer identity systems?

A: They succeed because many users reuse passwords and many systems still allow high-volume login attempts before friction or detection intervenes.

Q: How should teams handle account recovery as part of identity governance?

A: Teams should govern recovery as a high-risk lifecycle process, not a convenience feature.

Practitioner guidance

• Harden account recovery workflows Require step-up verification, delayed changes, and out-of-band alerts for recovery email or phone updates so attackers cannot silently replace trust anchors.
• Instrument credential stuffing detection Use rate limiting, device and IP reputation, breached-password checks, and repeated-failure correlation to spot automated login abuse before account takeover succeeds.
• Treat OTP bypass paths as privileged controls Review support scripts, fallback methods, and verification exceptions with the same scrutiny as administrative access because attackers target the weakest approval path.

What's in the full article

Axiad's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step explanation of how the credential stuffing and OTP bypass sequence worked in the Xfinity case
• Discussion of why SMS-based 2FA is especially vulnerable to bypass and interception patterns
• Practical guidance on passwordless adoption and what it changes in day-to-day authentication design
• User-facing considerations for reducing help-desk burden without weakening account recovery controls

👉 Read Axiad's analysis of the Xfinity breach and 2FA bypass →

Xfinity breach and 2FA bypass: what IAM teams should learn?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Twitter’s SMS 2FA glitches, rushed employee exits, and a reported 5.4 million-account breach exposed how authentication fragility and offboarding failures can converge during organisational upheaval, according to Axiad. The lesson is that access revocation, recovery paths, and phishing-resistant authentication cannot be treated as separate workstreams.

NHIMG editorial — based on content published by Axiad: Twitter's Authentication Nightmare

Questions worth separating out

Q: What breaks when SMS 2FA becomes unreliable during an identity incident?

A: When SMS 2FA becomes unreliable, users can be locked out, pushed toward weaker recovery paths, or lose confidence in the organisation’s access controls.

Q: Why do offboarding failures create so much identity risk?

A: Offboarding failures leave access active after the business relationship has changed, which means the organisation no longer knows who can still reach systems, data, or administrative functions.

Q: How should teams reduce risk from API endpoints tied to identity data?

A: Teams should inventory every API that can return account or profile data, then verify authentication strength, authorization scope, and whether the endpoint can return records in bulk.

Practitioner guidance

• Replace SMS-dependent authentication Move high-risk users and administrators to phishing-resistant MFA such as security keys or authenticator-based methods, and retire SMS for recovery and step-up access where possible.
• Run full-scope leaver revocation Disable directory access, revoke app sessions, remove device trust, and confirm privileged entitlements are gone across every connected system before closing the offboarding case.
• Review API-facing identity paths Identify which APIs can return bulk user data, then validate authentication strength, token handling, and entitlement scope for every service that can reach those endpoints.

What's in the full analysis

Axiad's full blog post covers the operational detail this post intentionally leaves for the source:

• A closer walkthrough of Twitter's authentication failures and the specific user-facing symptoms reported during the outage.
• The article's own discussion of offboarding risk when large numbers of employees depart at once and access revocation becomes messy.
• The source's treatment of the 5.4 million-record breach and how an API vulnerability tied the identity problem to data exposure.
• Axiad's recommended authentication direction for teams that want to move away from fragile SMS-based 2FA.

👉 Read Axiad's analysis of Twitter's authentication nightmare and offboarding risk →

Twitter authentication and offboarding gaps: what IAM teams missed?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Cisco’s breach analysis shows that stolen credentials, push-notification fatigue, and vishing can still defeat conventional MFA when attackers target the human approval path, according to Axiad. Phishing-resistant authentication and tighter push-app controls remain the practical answer, not more confidence in passwords or basic push prompts.

NHIMG editorial — based on content published by Axiad covering the Cisco data breach: lessons learned from Cisco's account compromise and MFA fatigue attack

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

Questions worth separating out

Q: How should security teams reduce MFA fatigue risk in push-based authentication?

A: Security teams should reduce MFA fatigue risk by limiting push enrollment, adding number matching or equivalent challenge friction, and monitoring repeated authentication prompts from the same source.

Q: Why do stolen credentials still matter when MFA is enabled?

A: Stolen credentials still matter because they give attackers a valid starting point inside the identity flow.

Q: What do organisations get wrong about push notification MFA?

A: Organisations often treat push MFA as if user approval were equivalent to strong proof of identity.

Practitioner guidance

• Shift high-risk accounts to phishing-resistant methods Use FIDO2 or PIV for administrators, remote access, and any account likely to be targeted with credential theft and social engineering.
• Tighten push-app registration controls Restrict where push authenticators can be enrolled, require stronger verification before device registration, and monitor for unusual re-enrollment activity after credential compromise.
• Train users on MFA fatigue and vishing cues Use realistic simulations that teach users to reject repeated prompts, challenge unsolicited support calls, and report unexpected authentication requests immediately.

What's in the full article

Axiad's full blog post covers the operational detail this post intentionally leaves for the source:

• Specific examples of push-notification abuse and how the attack chain unfolded in Cisco's environment
• Practical guidance on reducing MFA fatigue with stronger registration and enrollment controls
• Cisco-related lessons on phishing-resistant authentication choices for enterprise identity teams
• The vendor's implementation perspective on Axiad Cloud and Axiad ID for stronger authentication

👉 Read Axiad's analysis of the Cisco data breach and MFA fatigue lessons →

Cisco breach lessons and the MFA fatigue gap teams miss?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Three 2022 breaches show how exposed credentials, post-employment access, and phishing can still bypass enterprise controls, according to Axiad. The common failure is not just user error but weak identity governance over third parties, leavers, and authentication paths.

NHIMG editorial — based on content published by Axiad: 2022 Data Breaches, What Happened and What Did We Learn?

By the numbers:

• Three 2022 breaches illustrate how one exposed credential path, one leaver access failure, and one phishing campaign can produce very different outcomes.
• More than eight million users could be affected in the Cash App data breach disclosed in April 2022.
• At least 76 company employees and some of their family members received SMS phishing messages during the Cloudflare attack.

Questions worth separating out

Q: What breaks when third-party credentials are published in source code?

A: A public code leak becomes an access event when secrets remain valid after exposure.

Q: Why do leaver access failures create so much identity risk?

A: Because the identity no longer has a valid business reason to exist, yet the access can still function.

Q: How do you know if phishing resistance is actually working?

A: Test whether a stolen password alone can still complete sign-in.

Practitioner guidance

• Inventory credentials in public development assets Scan repositories, build artefacts, and shared code locations for embedded secrets, then confirm whether any exposed value still grants access.
• Bind offboarding to access revocation Remove human, contractor, and vendor access at the same time a relationship ends, and verify that report access, admin access, and API access all close together.
• Enforce phishing-resistant sign-in for privileged access Require hardware-based or equivalent phishing-resistant authentication for employees who can reach sensitive systems, and remove fallback paths that still accept replayable passwords or weak second factors.

What's in the full article

Axiad's full blog post covers the incident detail this post intentionally leaves at the pattern level:

• The full timeline for the Toyota, Cash App, and Cloudflare cases, including what was exposed and when each issue was discovered.
• The specific response steps each organisation took, including credential resets, access removal, and containment actions.
• The article's own interpretation of what these breaches suggest about password reliance and authentication design.
• The wording of Axiad's closing recommendations for organisations reviewing breach exposure and sign-in controls.

👉 Read Axiad's analysis of 2022 data breach patterns and identity failures →

2022 data breach patterns: what identity teams missed?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: The practical signal is that large-scale enterprise integration now depends on tightening identity control planes before sprawl turns into privileged access drift, according to Axiad’s Customer of the Year announcement, which centers on Accenture’s identity-first integration model, including phishing-resistant authentication, passwordless strategy support, and centralized governance across distributed Active Directories for thousands of users.

NHIMG editorial — based on content published by Axiad: Axiad names Accenture Customer of the Year for 2025

By the numbers:

• Accenture has completed nearly 100 acquisitions since 2023, according to Axiad.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.
• Only 5.7% of organisations have full visibility into their service accounts.

Questions worth separating out

Q: How should security teams govern authentication across acquired environments?

A: Treat authentication as a merger control, not a local IT preference.

Q: Why does standing privilege become a bigger problem during integration projects?

A: Integration teams often preserve elevated access to avoid disrupting operations, but that keeps legacy admin paths alive longer than necessary.

Q: How do you know if identity governance is actually working after an acquisition?

A: Look for fewer authentication exceptions, fewer retained administrator roles, and a smaller number of independent directory policies.

Practitioner guidance

• Standardise authentication across acquired environments Map every inherited directory and authentication path, then retire exceptions that let legacy systems keep separate login policies.
• Reduce standing privilege during integration Review administrator roles, delegated access, and transitional exceptions before the merged environment is normalised.
• Centralise governance for distributed directories Create one governance model for user, service, and privileged identities across all Active Directory estates, including those inherited from acquisitions.

What's in the full analysis

Axiad's full announcement covers the operational detail this post intentionally leaves for the source:

• How Axiad positions its identity platform across authentication, verification, and credential management use cases.
• The specific enterprise integration context behind the Customer of the Year recognition and the scale of the deployment.
• The product language around passwordless strategy, identity visibility, and post-quantum readiness.
• The vendor's own explanation of how the collaboration was framed with Accenture.

👉 Read Axiad's announcement on Accenture being named Customer of the Year →

Phishing-resistant authentication for integrated enterprises: what changes now?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: A malicious LiteLLM PyPI package injected code that harvested environment variables, cloud credentials, SSH keys, Kubernetes secrets, and other sensitive data, then exfiltrated them through attacker-controlled infrastructure, according to HiddenLayer. The incident shows how supply chain compromise can turn one compromised NHI into broad credential exposure, persistence, and cluster-wide access risk.

NHIMG editorial — based on content published by HiddenLayer: LiteLLM Supply Chain Attack

By the numbers:

• Version 1.82.8 was downloaded approximately 102,293 times.
• Version 1.82.7 was downloaded approximately 16,846 times during the period in which the malicious packages were available.

Questions worth separating out

Q: What breaks when a package can execute before the application starts?

A: The normal trust boundary breaks.

Q: Why do exposed NHI secrets create such a large blast radius in cloud environments?

A: Because one credential often unlocks many systems.

Q: How can security teams tell whether a supply chain compromise became a cluster risk?

A: Look for signs that the compromised code reached orchestration permissions.

Practitioner guidance

• Audit package startup execution paths Review Python environments for .pth files, import-time side effects, and unexpected interpreter startup hooks in production and build systems.
• Inventory and rotate exposed credentials immediately Treat any host that installed the affected package as compromised for secrets exposure, then rotate cloud keys, SSH keys, API tokens, and Kubernetes secrets.
• Restrict cluster privilege for build and runtime identities Verify that service accounts, pods, and CI/CD runners cannot create privileged workloads or enumerate cluster nodes unless there is a tightly scoped, reviewed requirement.

What's in the full article

HiddenLayer's full research covers the operational detail this post intentionally leaves for the source:

• IOC details for the malicious files, domains, and persistence artefacts observed in the package compromise.
• The exact package versions, file paths, and Kubernetes indicators that defenders can use for hunt queries and validation.
• The attacker infrastructure links and cryptographic indicators that connect this event to related supply chain compromises.
• Recommended response steps for rebuilding affected environments and checking for secondary compromise.

👉 Read HiddenLayer's research on the LiteLLM PyPI supply chain attack →

LiteLLM supply chain compromise: what IAM teams need to know?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: The Canvas breach exposed data from nearly 9,000 institutions after ShinyHunters exploited weaker identity verification in a free account tier that shared back-end infrastructure, showing how trusted vendor connections can turn a single identity boundary failure into a large-scale institutional exposure, according to Axiad. The breach is a reminder that visibility alone does not contain blast radius when third-party identity trust is too broad.

NHIMG editorial — based on content published by Axiad: The Canvas breach wasn't an IT outage. It was an identity crisis

By the numbers:

• Instructure confirmed approximately 275 million records were exposed across 8,809 institutions.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

Questions worth separating out

Q: What fails when a low-trust SaaS account tier shares infrastructure with institutional users?

A: The failure is not just access, but isolation.

Q: Why do trusted vendor connections increase identity risk in higher education?

A: Trusted vendor connections extend the identity attack surface beyond accounts your team directly manages.

Q: How can security teams tell whether identity visibility is actually helping?

A: Visibility helps only if it leads to prioritisation.

Practitioner guidance

• Separate low-assurance and institutional trust tiers Do not let freemium or self-service accounts share reachability with institutional data unless isolation is enforced at the authorization layer as well as the login layer.
• Review third-party and vendor-linked identity paths Inventory API connections, OAuth grants, service accounts, and delegated access that can inherit trust from a weaker identity path, then remove any route that crosses privilege boundaries.
• Prioritise phishing-resistant authentication for exposed populations Move students, faculty, and staff on high-risk platforms to phishing-resistant authentication where contextual data from a breach could support impersonation and code theft.

What's in the full article

Axiad's full blog covers the operational detail this post intentionally leaves for the source:

• The specific Canvas trust-tier breakdown and the account model that created the exposure path
• The article's step-by-step recommendations for rotating API keys and reviewing connected credentials
• The practical discussion of phishing-resistant authentication versus traditional MFA in this breach context
• The source's explanation of how higher education identity sprawl increases vendor-linked exposure

👉 Read Axiad's analysis of the Canvas breach and identity blast radius →

Canvas breach and identity blast radius: what IAM teams missed?

Explore further

View Full Forum →  |  NHI Foundation Course →

TL;DR: Sisense’s breach highlights how third-party compromise can turn identity trust into a supply chain problem, with Saviynt tying the incident to broader concerns about major supply chain attacks and downstream exposure. The lesson for practitioners is that vendor access, not just perimeter defense, now sits inside the identity threat model.

NHIMG editorial — based on content published by Saviynt covering the Sisense breach and broader supply chain attack risk

Questions worth separating out

Q: What breaks when supplier access is not tightly governed?

A: When supplier access is not tightly governed, a compromise in the third party can become your compromise.

Q: Why do third-party credentials increase supply chain risk?

A: Third-party credentials increase supply chain risk because they often combine standing privilege with broad operational reach.

Q: How do teams know if supplier identity governance is working?

A: Supplier identity governance is working when every external account has a clear owner, a narrow purpose, an expiry or review date, and continuous monitoring.

Practitioner guidance

• Inventory every supplier identity path Map accounts, tokens, API keys, certificates, and delegated admin links that let third parties reach production systems.
• Scope vendor access to explicit business functions Replace broad shared access with narrowly assigned permissions tied to named systems, named data sets, and named support workflows.
• Tie third-party access to lifecycle events Revoke or re-certify supplier access when contracts change, support ends, ownership changes, or integrations are retired.

What's in the full article

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

• The specific supplier and supply chain incidents referenced in the news roundup, including the context behind the Sisense breach.
• The vendor's framing of how third-party attacks relate to identity security platform strategy and product positioning.
• The other linked security stories in the roundup, which provide additional incident context beyond this post's identity-focused analysis.
• The source article's broader editorial context around recent cyber risk developments and identity security coverage.

👉 Read Saviynt's analysis of the Sisense breach and supply chain identity risk →

Sisense breach and supply chain identity risk: what teams missed?

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →

TL;DR: AI compresses vulnerability exploitation windows from days to minutes while zero-days and supply-chain flaws keep exposing enterprise software, according to CrowdStrike, Trend Micro, and Chainguard cited in SailPoint’s analysis. Versionless identity security matters because identity controls can no longer tolerate upgrade queues, fragmented patching, or delayed remediation.

NHIMG editorial — based on content published by SailPoint: The clock is ticking, why versionless identity security is no longer optional

By the numbers:

• The U.S. accounted for 130 of 251 global ransomware attacks against educational institutions in 2025 alone, a 27% increase year-over-year, with 3.9 million records exposed.
• 91% of organizations surveyed reported experiencing software supply chain attacks in the previous 12 months.
• 41% of those attacks originated from zero-day vulnerabilities in third-party code.

Questions worth separating out

Q: How should security teams evaluate versionless identity security in practice?

A: Evaluate whether the platform can remediate critical defects across all customers at once, without waiting for customer upgrades or maintenance windows.

Q: Why do versioned identity platforms create more risk during zero-day events?

A: Versioned platforms create staggered exposure because fixes must move through release branches, testing, and customer change control before they are fully effective.

Q: What should organisations ask vendors about critical identity patching?

A: Ask how quickly a fix reaches every tenant, whether older supported versions receive the same remediation path, and whether any customer action is required.

Practitioner guidance

• Map patch latency to control-plane risk Ask vendors how long critical identity fixes take to reach every tenant when the flaw is in their own code or a bundled dependency.
• Challenge version drift in procurement reviews Document whether the platform requires per-customer upgrades, maintenance windows, or branch-specific remediation.
• Review dependency exposure in identity platforms Require transparency on third-party components, especially where identity tooling depends on libraries that can introduce zero-day risk.

What's in the full article

SailPoint's full blog covers the operational detail this post intentionally leaves for the source:

• How SailPoint frames versionless, multi-tenant remediation mechanics across supported deployments
• The Log4Shell response timeline and the exact operational steps that enabled sub-six-hour remediation
• The vendor's argument for why identity security update cadence matters under AI-accelerated exploitation
• The specific comparison SailPoint draws between patch queues in versioned software and automatic fleet-wide fixes

👉 Read SailPoint's analysis of versionless identity security and patch queues →

Versionless identity security: are patch queues the real risk?

Explore further

View Full Forum →  |  NHI Foundation Course →