The most important cybersecurity lesson of 2026 is not that attackers have developed better malware.
It is that many of them no longer need malware at all.
Across some of the year’s most consequential attacks, threat actors gained control of legitimate accounts, administrative privileges, OAuth tokens, service accounts, third-party identities, or existing management tools. Once authenticated, they could often operate as trusted users—accessing cloud applications, exporting data, changing configurations, creating persistence, or disrupting operations.
The recurring problem was not simply authentication.
It was governance.
Organizations failed to continuously answer fundamental questions:
- Which identities still require access?
- Which accounts have administrative privileges?
- Who owns each service account and integration?
- Are third-party identities still necessary?
- Which applications can OAuth tokens access?
- Has a user’s access changed since the last review?
- Would anyone notice if a trusted identity suddenly behaved differently?
The following six incidents illustrate why identity has become the modern attack surface.
1. Storm-2949: One Identity Opened the Entire Microsoft Cloud
Microsoft’s investigation into Storm-2949 described an attack that began with targeted social engineering and identity compromise. The attackers abused self-service password reset processes, established persistence in Microsoft Entra ID, accessed Microsoft 365, and then expanded into Azure services.
From that initial identity foothold, the attackers reportedly reached SharePoint, OneDrive, Azure App Service, Key Vault, Storage, SQL databases, and virtual machines.
Microsoft emphasized that the attackers’ objective was broad data exfiltration across the victim’s high-value cloud assets. The campaign demonstrated how one compromised identity can cross the boundaries between SaaS, PaaS, and IaaS environments.
The identity mistake
The compromised identity had enough access—or could acquire enough access—to move across multiple cloud layers.
This was not merely a stolen-password problem. It was a failure to contain the privileges and relationships attached to that identity.
Once the attacker was authenticated, the environment’s legitimate permissions became the attack path.
The governance lesson
Organizations must review more than whether an account exists. They must understand:
- What the identity can access
- Which privileged roles it holds
- Whether those privileges remain appropriate
- Whether access to Microsoft 365 and Azure creates unintended pathways
- Whether unusual privilege or group changes trigger immediate review
A quarterly review may identify excessive access eventually. Identity Triggers can begin the review when the access change occurs.
2. The Stryker Attack: A Management Account Became a Destructive Weapon
The reported attack against medical technology company Stryker showed how dangerous a compromised management-plane identity can become.
Attackers allegedly compromised a highly privileged Microsoft Intune administrative account and used Intune’s legitimate remote-management capabilities to wipe a massive number of devices across dozens of countries.
Reports have differed on the exact number of devices affected, with estimates ranging from approximately 80,000 to 200,000. The central fact, however, is consistent: the attackers did not need to deploy conventional ransomware across every endpoint. They reportedly used an authorized administrative platform to issue destructive commands.
The identity mistake
An account with extraordinary operational power became a single point of failure.
The problem was not that Intune had remote-wipe capabilities. That is a legitimate administrative function.
The problem was that a compromised identity could exercise that function at enormous scale.
The governance lesson
Every organization should be able to immediately identify:
- Who has Intune administrative privileges
- Whether those privileges are permanent or temporary
- Whether each privileged account has a documented business owner
- Whether administrative duties are properly separated
- Whether one individual can both administer devices and approve sensitive actions
- Whether changes to privileged roles trigger an immediate access review
Attackers do not need malware when they already control the management plane.
3. Canvas: A Low-Friction Account Became an Enterprise Entry Point
Instructure disclosed unauthorized activity affecting its Canvas learning platform in the spring of 2026. The incident affected educational organizations around the world and exposed information including names, email addresses, student identification numbers, and some private messages.
Reporting and technical analysis indicated that the attackers exploited Canvas’s Free-for-Teacher account environment. Rather than compromising every educational institution independently, the attackers targeted an identity pathway within the shared platform.
The identity mistake
The organization treated a low-friction account type as lower risk, even though that identity existed inside a platform containing data from thousands of institutions.
This illustrates a common governance weakness: accounts are often evaluated by how they were created rather than by what they can reach.
A free, temporary, external, contractor, trial, or community account may still have access to valuable systems and data.
The governance lesson
Every identity should be governed according to its effective access—not its label.
Organizations need visibility into:
- Self-service and externally created accounts
- Guest and community identities
- Accounts without clear organizational ownership
- Dormant identities that remain active
- Unusual access relationships between low-trust accounts and sensitive data
An identity that is easy to create should not be difficult to govern.
4. NYC Health + Hospitals: Third-Party Access Expanded the Blast Radius
NYC Health + Hospitals disclosed that an unauthorized actor accessed certain systems between approximately November 25, 2025, and February 11, 2026.
The healthcare organization stated that the incident appeared to originate from a security breach involving a third-party vendor. The stolen files reportedly affected approximately 1.8 million people and may have included sensitive medical, financial, identification, and biometric information.
The identity mistake
Third-party access was able to become a pathway into sensitive internal systems.
Vendor identities frequently escape normal governance processes because they are not traditional employees. They may be created for a project, integration, support engagement, or implementation and then remain active long after the original need changes.
The account may belong to a vendor, but the risk belongs to the organization granting access.
The governance lesson
Third-party identities should be reviewed as rigorously as workforce identities.
Each one should have:
- An internal business owner
- A documented purpose
- A defined expiration or review date
- Access limited to the required systems
- Immediate removal when the engagement ends
- Monitoring for privilege or group changes
- Evidence showing who approved the access
Vendor access cannot be governed solely through contract language. It must be governed inside the identity environment.
5. Klue: A Legacy Credential and OAuth Tokens Reached Customer Environments
The Klue supply-chain incident demonstrated the risks created by SaaS integrations and long-lived machine access.
According to reporting on the incident, an attacker compromised a legacy credential associated with an integration service. The attacker then obtained OAuth tokens used by Klue integrations and accessed Salesforce data belonging to connected customer environments.
The incident affected multiple Klue customers and caused organizations to revoke tokens and disable affected integrations.
The identity mistake
A legacy non-human credential retained access to a production integration environment.
The OAuth tokens were not passwords in the traditional sense, but they functioned as identities. They allowed software to authenticate, make API calls, and access data without a human logging in each time.
This is precisely why non-human identities must be included in identity governance programs.
The governance lesson
Organizations should be able to identify:
- Every service account
- Every OAuth integration
- Every API token and application credential
- The human owner responsible for each non-human identity
- The systems and data each integration can access
- When the credential was last used or rotated
- Whether the access is still required
- Whether the application’s permissions are broader than necessary
A service account without a current owner is an orphaned identity.
An OAuth token without periodic review is long-lived trust without continued justification.
6. FortiBleed: Predictable Administrator Identities Became the First Target
The FortiBleed campaign targeted internet-accessible Fortinet devices using exposed or compromised credentials.
CISA reported leaked credentials associated with approximately 74,000 Fortinet devices, including firewalls and VPN gateways. Other reporting connected the operation with hundreds of completed intrusions and subsequent ransomware activity.
One especially concerning finding was that approximately 63% of the harvested credentials were associated with default, generic, or never-renamed administrator accounts.
The identity mistake
Organizations protected the network perimeter while leaving the identities controlling that perimeter predictable and overexposed.
Built-in administrator accounts often accumulate risk because they:
- Are universally recognizable
- May be shared by multiple administrators
- Lack individual accountability
- Are difficult to associate with a human owner
- May retain privileges indefinitely
- Are frequently excluded from normal access-review campaigns
The firewall may be the perimeter, but an administrative identity controls the firewall.
The governance lesson
Built-in and local administrator accounts must be governed like every other privileged identity.
Organizations should review whether:
- Default administrator accounts are still enabled
- Generic accounts can be replaced with named identities
- Shared credentials are being used
- Every privileged account has an accountable owner
- Dormant administrator accounts remain active
- New local accounts have been created without authorization
- Privilege changes trigger investigation and review
The most important accounts to review are often the ones organizations assume will always exist.
The Common Denominator Was Identity
These incidents involved different industries, technologies, attacker groups, and objectives.
Some resulted in data theft. Others caused operational disruption. Some began through phishing, others through vendors, tokens, default accounts, or privileged administrative access.
But the common pattern was consistent:
- An identity was compromised, misused, inherited, or insufficiently governed.
- That identity already possessed—or could obtain—valuable access.
- The attacker used legitimate permissions and trusted systems.
- Excessive, persistent, or poorly understood access expanded the impact.
The attacker’s most powerful tool was often not malicious code.
It was authorized access.
How YouAttest Identity Governance Reduces the Risk
No identity-governance platform can guarantee that credentials will never be stolen or that users will never be deceived.
The objective is to reduce what an attacker can do after obtaining an identity—and to identify dangerous changes before they become major incidents.
YouAttest Automated User Access Reviews
YouAttest User Access Reviews help organizations verify that employees, administrators, contractors, vendors, and other identities still require their assigned access.
Regular reviews can identify:
- Excessive privileges
- Access retained after role changes
- Dormant and ghost accounts
- Inappropriate group memberships
- Unnecessary access to sensitive applications
- Privileged accounts without sufficient justification
Automation allows these reviews to occur more frequently without relying on spreadsheets, email chains, and manual evidence collection.
YouAttest Non-Human Identity Reviews
Service accounts, API keys, OAuth applications, bots, integrations, and AI agents can possess access equal to—or greater than—human users.
Non-human identity reviews establish:
- A human owner for each identity
- Its business purpose
- The systems it can access
- Whether the identity is still active
- Whether credentials should be rotated
- Whether permissions remain appropriate
- Whether the identity has become orphaned
The Klue incident is a clear example of why machine access cannot remain invisible to governance teams.
YouAttst Segregation of Duties Analysis
Segregation of Duties controls reduce the likelihood that one identity can independently perform every step of a sensitive or destructive process.
SoD analysis can identify toxic combinations such as:
- Creating and approving access
- Administering devices and authorizing destructive actions
- Modifying financial data and approving transactions
- Managing users and reviewing one’s own privileges
- Creating service accounts and approving their production access
Privileged access should not only be limited. It should also be structurally separated.
YouAttest Identity Triggers
Periodic reviews provide essential evidence, but risk does not wait for the next quarterly campaign.
Identity Triggers allow governance workflows to respond to significant events such as:
- A user being added to a privileged group
- An administrator role being assigned
- An account becoming dormant
- A new external or guest user appearing
- A service account losing its owner
- A terminated employee retaining access
- A sensitive permission changing
YouAttest can use these events to automatically launch an access review, notify the appropriate reviewer, and create a record of the resulting governance decision.
This moves identity governance from periodic compliance toward continuous identity risk management.
The Question Every CISO Must Answer
The question is no longer simply:
Can an attacker get through our perimeter?
The more important question is:
What could an attacker do if they gained control of one trusted identity?
- Could that identity export customer data?
- Could it access SharePoint, Salesforce, or Azure?
- Could it wipe devices?
- Could it approve its own access?
- Could it generate new OAuth tokens?
- Could it operate through a third-party connection?
- Could it remain active for months without a business owner?
The breaches of 2026 show that organizations cannot protect modern environments without continuously understanding and governing the identities inside them.
Attackers do not always break in.
Increasingly, they log in—and use the access organizations have already granted them.
YouAttest helps organizations automate User Access Reviews, govern human and non-human identities, detect Segregation of Duties conflicts, and launch immediate governance workflows in response to identity events.
Contact us today to schedule a personalized demonstration and see how YouAttest can help your organization reduce risk, improve security, and simplify compliance.
Contact YouAttest: https://youattest.com/contact
Identity Governance. Automated. Evidenced. Defensible.
- AI Agents Are Privileged Identities. Their Access Needs to Be Reviewed. - October 3, 2026
- AI Is the Unrealized Insider Threat: Why Enterprise AI Security Starts With Existing User Access - September 20, 2026
- The Service Account Wasn’t the Initial Breach. It Became Part of the Attack. - September 13, 2026
