Security response · October 2026
Your password isn’t the only way into your app
Your team may know who can sign in and still lack an inventory of what can connect. Backup services, deployment tools, reporting apps, and agents can hold permissions of their own. During an incident, those connections need names, owners, and a way to stop their access.
Incident guidance can change. Use the linked vendor notices for current scope and instructions.
Quick answer
A password reset is not a complete response to compromised application access. Identify the connected application's identity, credentials, and granted permissions. Follow the provider's containment guidance, verify the relevant controls, and review activity. The important question is which authority the application can still exercise after the change.
What the October ConnectWise report illustrates
On 21 October, Microsoft described Storm-0940 using the ARTEX framework in a campaign that included abuse of a compromised ConnectWise application already authorized in customer environments. Microsoft observed activity without interactive user sign-in, followed by reconnaissance and application-credential or privilege changes. It said the activity did not result from a vulnerability or compromise of Microsoft products or corporate systems.
Microsoft reported privileged access in under three hours in some cases. That is an observation about those cases, not a response-time forecast for every organization. Successful authentication also does not, on its own, prove data access or exfiltration. Microsoft's original report.
The practical lesson is to inventory trusted access before an emergency. A sign-in page is only one part of that inventory.
How an application has access without a person signing in
Microsoft distinguishes delegated access, where an app acts on behalf of a signed-in user, from app-only access, where it acts as its own identity. The latter supports background services and backup jobs. Its permission grant needs to be reviewed as application authority. Microsoft permissions and consent overview.
This conceptual diagram shows the authorization relationship, not a reconstruction of the reported attack:
Keep people, application credentials, and permission grants as separate entries in the response record. Changing one entry does not establish what happened to the others.
Build a connected-service inventory
Start with services that can read business data, deploy code, manage other identities, or change backups. Include dormant connections and accounts managed by an outside provider.
| Field | What to record |
|---|---|
| Business purpose | Why the connection exists and which workflow needs it |
| Identity | Immutable application/client ID and local object or service identity ID where available |
| Authority | Delegated access, application access, API key, or another documented mechanism |
| Granted access | Actual scopes, roles, resources, and tenant/project boundaries |
| Credentials | Identifier, owner, expiry, and storage location; never the secret value |
| Owners | Business approver, technical operator, and administrator who can contain access |
| Activity evidence | Where sign-ins, administrative changes, and resource operations are recorded |
| Revocation path | Exact control, authorized role, and provider instructions |
| Dependency | What stops working if access is contained |
| Verification | How the team confirms the control changed and what remains unresolved |
Use the integration inventory worksheet. The example rows are prompts, not findings about any company.
Map the revocation path before you need it
“Disconnect the app” can mean different things in different products. Have the responsible administrator identify the applicable control and the evidence it produces.
| Authority involved | Response to identify with its owner | Verification question |
|---|---|---|
| Human account or session | Account/session containment and credential response | Which sessions and credentials remain valid? |
| Application credential | Issuer-side revocation or replacement | Can that credential still obtain or use access? |
| Granted permission | Relevant consent, role, or resource-access change | Which effective permissions remain? |
| Integration identity | Provider-supported disabling or containment | Is the intended application identity blocked, in each affected account? |
| Additional unauthorized access | Investigation and removal of confirmed changes | Were other credentials, grants, owners, or identities created? |
Microsoft's permission review guide treats delegated and application permissions separately and notes other authorization systems. Its current guidance also warns that revoking a grant does not by itself prevent users from consenting again. Include that possibility in the owner's verification plan.
What should a Cloud Backup customer do
Use the current ConnectWise Trust Center guidance and its linked technical investigation guide. At the reviewed update of 23 October 01:00 UTC, ConnectWise continued to tell customers to keep affected connections disabled until applicable restoration instructions.
The vendor guide separates vendor-side containment from customer-tenant configuration and says previously issued tokens may remain usable until expiry or invalidation. It calls for review in each administered tenant, including dormant connections. Use its current immutable application IDs and record local object IDs; display names alone are insufficient.
Have an authorized responder preserve evidence, contain access, and investigate changes. Do not delay urgent containment for a complete export, and do not treat deletion of the application as a substitute for investigating the access it exercised.
Three assurances that need more evidence
| Assurance | Follow-up question |
|---|---|
| We reset everyone's passwords | What happened to application credentials and granted access? |
| The vendor disabled the integration | Which customer-side controls changed, and which still need verification? |
| There are no suspicious sign-ins | Which identity categories and time periods were available, and what resource activity was reviewed? |
For the reported campaign, Microsoft recommends correlating service-principal sign-ins with subsequent activity and configuration changes. An absence of a particular log result must be interpreted within telemetry coverage. Keep a record of missing history and the limits of each conclusion.
Who owns the response
Assign one business owner to decide whether the connection is still needed, one administrator with authority to contain it, and one responder to investigate activity. The same person may fill several roles, but record the assignments explicitly.
Before restoring service, obtain the vendor's applicable restoration guidance, verify the intended configuration, and complete the required checks. A familiar display name or a working backup job does not close the investigation.
Questions app owners ask
Does MFA solve this class of access
MFA protects relevant user authentication flows. App-only access uses application authority without a signed-in user, so review it separately. Keep human sign-in protection alongside the application identity and permission inventory.
Can a public URL scan review these permissions
No. A scan of a website does not inspect private Microsoft 365 tenant grants, developer machines, private keys, or the patch state of every server. Use administrator evidence for those claims. The live scan versus source review guide maps different security questions to their evidence.
For implementation details in an application you build, use the OAuth security guide. For the broader incident triage, use October's security decision resource.
Cite this guide
Vibe App Scanner. “Your password isn’t the only way into your app.” Sources reviewed 22 October 2026 in Toronto. The campaign account is attributed to Microsoft and ConnectWise. The conceptual diagram, inventory, and ownership checklist are editorial tools; no customer tenant or connected account was inspected for this article.