Skip to main content
decorative

Blog

Updates and insights from the compliance and security front lines

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

‍What ConnectWise and OpenCode tell CISOs about machine identities

‍
Facts as reported through October 21st, 2026. Both incidents are still under investigation.

In three weeks I will be in Lisbon for Web Summit. This year its cybersecurity track runs under the theme "machines versus machines" (Web Summit). Last week gave us two clear examples of what that means in practice. Neither involved a person typing a password.

Two incidents, one pattern

ConnectWise Cloud Backup. On October 15, a credential belonging to ConnectWise Cloud Backup (formerly SkyKick) was used to sign in to customer Microsoft 365 tenants and collect access tokens. Huntress confirmed unauthorized sign-ins in 162 tenants as of October 16. In one tenant, a related ConnectWise app made itself Global Administrator and added new secrets to other apps (Huntress). ConnectWise has disabled the affected app identities and suspended the service while it investigates (ConnectWise).

OpenCode Console. On the night of October 16, an intruder reached a legacy system at OpenCode, maker of an AI coding tool. OpenCode told the affected 1.4% of its hosted Console users to revoke and replace the OpenAI, Anthropic and Google keys they had saved there (The Hacker News). OpenCode says the keys "may have been exposed" and has not confirmed that any were copied or used. Some users report unauthorized charges, with one user putting the loss at $1,700 (The Hacker News). OpenCode's email to affected users mentions possible reimbursement (BleepingComputer).

One is a backup tool. The other is an AI tool. The shared story is the credential: a machine identity, held by a third party, with standing access, and no person involved when it is used.

Both companies moved quickly to tell customers what to do. The lesson here is not about them. It is about how all of us manage this kind of access.

What machine credentials skip

These credentials bypass the controls most security programs are built around.

  • No MFA. App-only sign-ins involve no user and no device, so there is no MFA prompt to stop them (Huntress).
  • A thin trail. Some Microsoft Graph reads leave no audit record (Huntress).
  • Your off switch may not be the real one. Deleting a key from OpenCode Console does not revoke it, and a Console budget cannot cap its use, because Console only sees requests that pass through its own gateway. The key has to be revoked at the AI provider (The Hacker News). In the ConnectWise case, disabling the vendor apps did not remove secrets already planted on other apps.

Scale makes this harder. The Cloud Security Alliance, citing Entro Security research, says non-human identities now outnumber human users in the enterprise by an average of 45 to 1 (Cloud Security Alliance). Many were approved once, by someone who, potentially, may no longer still be employed by your organization.

The policy is fine. The evidence is missing.

Almost every security leader I talk to has a policy for third-party access and secrets. Least privilege. Rotate keys. Review access every quarter. But a quarterly review tells you what was true on the day someone looked. In one ConnectWise tenant, the whole sequence from Global Admin to planted secrets took about five minutes.

So the useful question for a CISO is not "do we have a policy?" It is "could I show my board, today, that the policy is being followed?"

Five questions for your next leadership meeting

  1. How many third-party apps and AI tools hold standing access to our core systems, and who owns each one?
  2. Which of them can change permissions or credentials for other apps?
  3. Where do our AI provider keys live, including copies held by hosted tools? Does each tool have its own key, with a spend limit set at the provider?
  4. How fast could we revoke and replace every credential tied to one vendor? Have we tested it?
  5. If a vendor told us tomorrow that its credential was stolen, what could we prove within 24 hours about what that credential did in our environment?

That last question matters more in Europe every month. Since September 11, manufacturers covered by the EU Cyber Resilience Act must send an early warning within 24 hours of becoming aware of an actively exploited vulnerability or severe incident, and a full notification within 72 hours (European Commission). Reporting clocks are getting shorter, and machine identities are where the facts are hardest to find.

Where Crowsnest fits

At Crowsnest we turn security logic into automated controls against real systems and provide continuous evidence of whether controls are working. Rules like "every machine credential has an owner" and "no third-party app holds admin rights" are exactly the kind of policy that should be checked all the time, not reviewed once a quarter.

Let's talk in Lisbon

We will be at Web Summit at the MEO Arena and FIL in Lisbon, November 9 to 12. If you are working through machine identities, AI tool sprawl, or third-party access, I would like to hear how your team handles the evidence today. Come by our booth or book time with me: https://calendar.app.google/usXe3A5Har3dWMrf9

Sources

‍

Your AI tools have keys. Do you know where they are?

October 22, 2026

-

111

Min Read

When an engineering or IT team integrates a third-party SaaS tool—whether for cloud backup, log aggregation, or asset management into Microsoft 365, Google Workspace, AWS, or alike—the transaction feels routine. The admin consents to scoped API permissions so the integration can sync mailboxes, replicate data stores, or parse telemetry.

That is the declared policy. The events of mid-October 2026 showed what a system can actually do with that consent.

Between 06:13 and 08:34 UTC on October 15, an attacker used compromised credentials belonging to ConnectWise Cloud Backup (formerly SkyKick) to initiate automated Microsoft Graph token requests across customer tenants. Incident response telemetry from Huntress identified sign-in activity targeting nearly 1,000 organizations, confirming unauthorized access in over 300 tenants.

The credential originated directly within ConnectWise’s internal infrastructure. In Huntress’s words: "Nothing a customer did in their environment could have produced it."

While mass token requests represented broad reconnaissance, the critical architectural lesson took place inside a customer tenant investigated by Huntress: at 03:44 UTC, a related identity from the same ecosystem—ConnectWise Cloud Management for Microsoft Teams—promoted itself to the Global Administrator directory role. Within five minutes, it generated and attached new client secrets (configured to expire in 2028) to two unrelated applications in the tenant: an MSP management tool and Huntress's own security platform. Huntress subsequently identified the identical self-elevation and persistence pattern in a second tenant.

ConnectWise responded transparently, disabling seven application identities, suspending affected services, and releasing detailed remediation guides. Microsoft confirmed that the attacker abused broad application permissions previously granted by customers, specifically high-privilege scopes such as Directory.ReadWrite.All.

The policy said: "Backup data."
The runtime execution said: "Grant Global Administrator and plant secondary backdoors."

1. The Non-Human Identity (NHI) Problem Is Universal

While this incident unfolded within Microsoft Entra ID, the vulnerability is not unique to Microsoft. It is the systemic design of modern cloud architecture.

Whether managing Microsoft 365, AWS, Google Cloud, Salesforce, or modern developer pipelines, the majority of access is no longer human. It belongs to Non-Human Identities (NHIs): OAuth applications, service principals, cross-account IAM roles, and automated machine agents.

These programmatic identities bypass the entire security stack engineered for human operators:

  • Zero Interactive Friction: Service principals and IAM roles do not answer MFA prompts, undergo biometric verification, or carry physical FIDO2 security keys.
  • Conditional Access Blind Spots: Security teams routinely exempt automated data pipelines and third-party SaaS tools from location and IP restrictions to avoid breaking operational syncing. Once an API token or credential is stolen, the bearer can execute requests from any hosting provider IP in the world.
  • Asymmetric Logging: Across Microsoft 365 and major cloud control planes alike, programmatic directory reads frequently leave zero forensic trace, or strip originating IP addresses from basic-tier telemetry logs, leaving security teams blind to the true blast radius.

The attacker did not breach an endpoint or bypass an authentication challenge. They leveraged an authorized programmatic token to execute capabilities granted during an administrative onboarding flow approved years prior.

2. Remediating the Vendor vs. Remediating the Environment

One of the most critical warnings highlighted in ConnectWise’s remediation documentation applies to every cloud ecosystem: disabling the vendor's integration does not undo actions already executed inside your environment.

Identity-based attacks rely on decoupling the initial entry point from long-term lateral persistence:

‍

If an organization simply disconnects the vendor application, the attacker loses that initial front door. But if that application was used to inject an API secret into a secondary, trusted enterprise application within Microsoft 365 or an IAM role in an AWS account, the attacker retains persistent programmatic access under an entirely different identity.

‍

Remediation cannot stop at the perimeter of the compromised supplier; it requires continuous, deterministic verification of every downstream identity object in the environment.

3. The Scanner Trap: Why Identity Drift Bypasses Traditional Tools

Traditional vulnerability management relies on matching installed components against lists of known-bad artifacts (CVEs). If an unpatched binary or an outdated library is discovered, a ticket is raised.

The ConnectWise incident illustrates why this model cannot protect modern cloud environments:

  1. Zero Outdated Binaries: The cloud APIs, identity endpoints, and vendor services were running fully supported, current code.
  2. Authorized by Design: An identity holding permissions like Directory.ReadWrite.All or RoleManagement.ReadWrite.Directory that modifies directory roles or generates application secrets is fundamentally valid within the API specification.
  3. The Architectural Reasoning Gap: The failure is architectural, not a software bug. A static scanner cannot distinguish between an authorized administrative script updating application secrets and an attacker backdooring a tenant via an automated loop.
Scanners check inventory against known-bad catalogs. They cannot reason about your actual operational intent.

4. Turning Cloud Identity Governance into Behavioral Contracts

Most organizations maintain documented identity governance policies stating: "Third-party applications must adhere to least privilege, and administrative privileges are reserved strictly for authorized human personnel."

Yet almost no organization can mathematically prove whether that statement remains true between annual audits.

At Crowsnest, we built our platform to eliminate this gap by translating declared security policies into machine-enforceable Behavioral Contracts evaluated continuously at runtime:

  • Continuous Control Plane Verification: Rather than running periodic point-in-time scans, Crowsnest continuously evaluates directory roles, app registrations, service principals, cross-account IAM roles, and credential creations across Microsoft Entra ID, cloud infrastructure, and connected platforms on every state change.
  • Deterministic Invariant Enforcement: Behavioral contracts such as "No non-human identity may assign directory roles to itself" or "No third-party service principal may create credentials on peer applications" are evaluated immediately. If an identity attempts to cross those boundaries, drift is surfaced instantly with timestamped evidence.
  • Run Everywhere, In-Tenant, Zero Data Exfiltration: Evaluating cloud and identity posture should not require shipping sensitive directory metadata, employee details, or access logs to an external multi-tenant SaaS vendor. Crowsnest deploys directly into your environment—running on-host, on-cluster, and in-tenant via CrowAI. No customer operational data leaves your environment, giving you continuous proof while preserving absolute data sovereignty.
A policy that is not evaluated continuously at the runtime API layer is merely an assumption.

5. Technical Audit: What Engineering & Security Teams Must Run This Week

Whether managing Microsoft 365, AWS, Google Cloud, or hybrid environments, execute these technical checks immediately:

1. Audit All High-Privilege Roles Held by Non-Human Identities: Query your identity providers for third-party service principals, OAuth apps, or cross-account IAM roles holding administrative privileges (e.g., Global Administrator, Privileged Role Administrator, or AdministratorAccess policies). Ensure every assignment has a verified owner, a documented ticket, and an active business justification.

2. Scan for Stale and Newly Created Application Credentials: Export all client secrets, certificates, and programmatic access keys across your cloud providers. Filter for credentials created between October 13 and the present. Cross-reference every key against internal engineering change orders; immediately revoke any credential lacking documented lineage.

3. Implement Real-Time Alerts for In-Tenant Self-Elevation: Configure continuous monitoring on directory and audit logs (such as Entra ID Audit Logs or AWS CloudTrail) for two high-risk events:

  • Programmatic role assignments where the initiator is an app-only service principal or non-human identity.
  • Credential creation events where one service principal or automated workflow generates secrets or certificates on another application.

4. Inspect Conditional Access & IP Allowlist Exclusions: Review every policy enforcing trusted network locations or device-compliance checks. Identify every third-party service principal or workload identity explicitly excluded from these boundaries.

5. Verify Telemetry Retention Limits: Audit your retention windows across cloud control planes. Standard tiers often retain sign-in and audit telemetry for only 7 to 30 days. If your control plane logs are not being streamed into cold, immutable long-term storage, investigating an intrusion that occurred weeks prior becomes mathematically impossible.

The lesson from the ConnectWise incident is clear: modern compromises do not wait for quarterly audit cycles, and adversaries do not limit themselves to software bugs. They exploit the open permission surface of trusted non-human identities.

If your security posture relies on assuming an approved cloud application behaves only as intended, you are operating on assumption. Closing that gap requires continuous runtime evidence that your systems—and every external identity inside them—execute strictly within the behavioral boundaries you define.

Sources & References

  • Huntress Technical Analysis: Vendor Credential Enables Unauthorized Access across M365 Customers
  • ConnectWise Trust Center: Cloud Backup Service Interruption Advisory & Remediation Guide
  • The Hacker News: Hackers Abuse Compromised ConnectWise Credential to Target Microsoft 365 Tenants

‍

Your Backup Vendor’s App Just Became a Global Admin: Non-Human Identity Drift Across Microsoft 365, Cloud Platforms, and Alike

October 19, 2026

-

111

Min Read

On the night of Sunday, October 11, attackers compromised the refrigeration infrastructure across hundreds of French supermarkets, hitting chains including Intermarché, Coopérative U, E.Leclerc, Carrefour Market, and Monoprix.

Rather than deploying conventional extortion ransomware against back office databases, the attackers altered the operating logic of Danfoss refrigeration controllers, driving units into permanent defrost cycles. Temperatures inside industrial cooling systems rose to 50°C (122°F). Fresh and frozen stock across entire regional hubs had to be destroyed, and Paris prosecutors confirmed that thermal overloads sparked localized fires.

France’s cybersecurity agency, ANSSI, via CERT-FR, issued an emergency alert identifying compromised Danfoss controllers, specifically legacy AK-SM 800 and AK-SC 355 units (both long past their end-of-life dates), alongside current generation AK-SM 800A controllers operating on outdated firmware.

Danfoss noted that advisories had long urged customers to update. The fixes existed. The deployed systems simply did not have them.

The core issue here is not that grocery chains failed a routine compliance review. It is that modern security posture management relies on a fundamentally obsolete model: the assumption that documented intent matches operational execution.

The Three Layers of System State

Every enterprise operating connected infrastructure has three distinct versions of reality:

  • Declared Intent (Policy): The documentation, compliance checklists, SOC 2 control mappings, and vendor questionnaires stating how systems ought to run.
  • Recorded Configuration (Control Plane): What the central management dashboard, API console, or configuration database reports.
  • Execution Reality (Runtime): What the edge microcontroller, bare metal register, kernel module, or running process is actively doing right now.

Virtually all conventional Governance, Risk, and Compliance (GRC) and Security Posture Management tools live strictly within layers 1 and 2. They poll APIs, parse static IaC scripts, ingest configuration files, and match them against static control frameworks.

In France, the policies mandated precise cold chain standards. The vendor questionnaires likely certified baseline compliance. But the physical execution state diverged catastrophically: the policy said "cold," and the physical setpoint registered 50°C.

A security control does not exist unless the system is actively enforcing it at runtime.

The Third-Party Trap: From "123456" to Industrial Edge

The Danfoss vulnerability demonstrates how deeply third party dependencies sit inside your attack surface. You can run strict internal identity controls, but if a third party maintenance vendor maintains an unverified remote access tunnel to an edge gateway, your perimeter is non-existent.

We saw this exact systemic vulnerability just days prior in Denmark. The Danish national CPR register containing personal records on approximately 8.8 million people was breached after an attacker accessed accounts at Pays ApS, an external IT service provider with authorized system access. The administrative entry point was an account secured with the password 123456.

Whether it is an IT vendor managing citizen databases or a refrigeration contractor managing supermarket cooling loops, the pattern remains identical: access is granted based on an upfront assumption of compliance, with zero continuous verification of runtime behavior.

A vendor questionnaire asks what a supplier intends to do. It cannot tell you what their software or remote tunnel is executing inside your network right now.

The Modern Architectural Sprawl: Hardware, Cloud, and Agentic Code

Securing this surface is no longer a matter of simply telling technicians to patch edge controllers. Enterprise engineering footprints have expanded into a complex, heterogeneous topology:

  1. Hardware & Edge OT: Legacy microcontrollers, programmable logic controllers (PLCs), and building management engines running constrained firmware and proprietary protocols.
  2. Centralized Cloud Workloads: Ephemeral microservices, dynamic Kubernetes nodes, and multi-cloud API gateways with continuous configuration changes.
  3. Agentic and Autonomous Systems: Autonomous AI agents, automated CI/CD runners, and automated orchestration workflows executing code and modifying parameters without human mediation.

These environments are deeply interconnected. A centralized cloud optimization service writes adjustments down to an edge controller; an AI code agent pushes infrastructure updates to production clusters.

When configuration drift or an intrusion occurs anywhere across this continuum, point-in-time scanners and legacy Cloud Security Posture Management (CSPM) tools fail:

  • Static scanners cannot inspect the real-time register states of edge OT controllers.
  • Traditional perimeter tools cannot distinguish an authorized optimization change from an attacker overriding a setpoint via an authorized vendor pipe.
  • Centralized dashboards cannot react at the speed of autonomous, agentic configuration drift.

The Privacy and Data Sovereignty Imperative

When confronted with edge-to-cloud security blind spots, traditional cybersecurity vendors typically propose a brute force solution: mirror all raw operational logs, telemetry, and payload traffic into a centralized, third party cloud data lake for analysis.

For critical infrastructure, industrial operations, and privacy sensitive enterprises, that approach creates severe structural problems:

  1. Supply Chain Exposure: Aggregating raw operational and process data into external SaaS repositories creates a high-value single point of failure.
  2. Regulatory & Sovereign Friction: Transporting operational telemetry across jurisdictions violates critical infrastructure rules, NIS2 requirements, and data sovereignty principles.
  3. Bandwidth and Latency Constraints: Edge and OT environments cannot continuously stream gigabytes of raw sensor data across the public internet just to evaluate basic compliance invariants.

Modern posture management must abandon centralized telemetry surveillance. Instead, it requires sovereign, in place validation engines.

Posture evaluation must execute locally directly on the edge node, within the private VPC, or alongside the autonomous agent runtime. Verification must test system state against cryptographically signed behavioral invariants, outputting verifiable proofs of state without exposing or exfiltrating underlying operational data.

Continuous Behavioral Posture: The 4 Invariants

Addressing these systemic vulnerabilities requires an integrated posture architecture engineered around four foundational principles:

  1. In Place, Sovereign Execution: Validate configuration and runtime behavior where the system lives. Retain 100% data ownership. Export only cryptographic state proofs and drift alerts, never raw customer or operational payloads.
  2. Unified Scope (Edge, Cloud, and Agentic Code): Treat edge PLCs, infrastructure-as-code files, API access paths, and autonomous AI agents as a unified execution graph. If a component can affect state, it must be subject to continuous posture verification.
  3. Deterministic Behavioral Checks: Move beyond asking "Does this vendor claim to follow our policy?" Run deterministic tests: Can an unauthorized identity reach this controller interface? Does this firmware match an approved hash? Is this setpoint within safe operational bounds?
  4. Immediate Drift Attribution: When a system drifts, attribution must be instantaneous: determine whether the change originated from a scheduled engineering job, an autonomous optimization agent, or an unauthorized lateral connection.

What Engineering Leaders Should Audit This Week

If you oversee connected operational technology, edge systems, or hybrid cloud environments, begin with these technical baselines:

  • Map All Setpoint-Modification Paths: Identify every logical path capable of altering physical or operational thresholds. Treat third party vendor access paths as high privilege execution vectors rather than passive monitoring feeds.
  • Isolate Unpatchable Legacy Assets: End-of-life firmware that no longer receives security updates (like the Danfoss AK-SM 800 series) cannot be trusted on reachable networks. Place legacy controllers behind zero trust isolation proxies.
  • Convert Policies into Machine-Verifiable Invariants: Translate human readable policy assertions into programmatic constraints evaluated continuously. Replace "vendor connections are secured" with an automated check that continuously flags any inbound session lacking verified mutual authentication.
  • Audit for Deviation, Not Just Signatures: An unexpected setpoint shift is an immediate indicator of failure or compromise, regardless of whether signature based IDS/IPS tools trigger an alert.

Closing the Gap Between Intent and Reality

The supermarket attack in France is a clear demonstration that operational systems do not fail because organizations lack policies. They fail because operational reality drifts away from administrative intent without anyone noticing until physical damage occurs.

As systems become increasingly autonomous, distributed, and tied to physical outcomes, checking compliance on paper or via quarterly audits is no longer viable.

At Crowsnest, we build continuous posture automation that turns security requirements into verifiable, in-place checks across edge hardware, dynamic cloud infrastructure, and autonomous code delivering provable security while preserving absolute data ownership.

Sources & References

  • CNN: French Supermarket Refrigeration Cyberattack (Reporting on retail compromises and physical temperature impacts)
  • France 24: Retailers Confirm Supermarket Cyberattack (Store disruption details across French chains)
  • CERT-FR / ANSSI: Alert on Danfoss Refrigeration Controllers AK-SM and AK-SC Series (Mitigation and isolation guidance)
  • Cybernews: Denmark CPR Data Breach via Weak Password (Third-party supplier compromise exposing 8.8M records)

‍

The Fridge Was Set to Cold. The System Said Otherwise: Why Modern Posture Demands In-Place Verification Across Edge, Cloud, and Agentic Systems

October 15, 2026

-

111

Min Read

No Results.

Prove your systems are doing their job

See how Crowsnest helps security teams uncover blind spots, validate coverage, and prove what their stack is doing.