ConnectWise Cloud Backup Breach: Microsoft 365 Investigation and Recovery

The ConnectWise Cloud Backup breach requires a tenant investigation, a review of application trust, and a separate plan for interrupted backups. A statement about stored backup archives cannot establish whether an application identity accessed a live Microsoft 365 tenant. Likewise, disabling an original connection cannot establish that every subsequent permission or credential change has been removed.

At the October 19, 2026, 01:15 UTC update reviewed for this article, ConnectWise said Cloud Backup, SaaS Security, and Cloud Management remained suspended without a confirmed restoration time. Its investigation identified compromised application identities; the original credential-exposure mechanism remained under investigation. The company reported no evidence that its encrypted, isolated backup archives had been accessed. Administrators should consult the live ConnectWise advisory before acting because service status and required recovery steps can change.

For an organization using Cloud Backup, formerly SkyKick, the immediate operational question is concrete: which identities could reach this tenant, what evidence remains of their activity, and what must be verified before access resumes? Answer it for the MSP’s own tenant and independently for every managed customer. A partner relationship does not make those environments share the same permissions, logging, or evidence.

What the incident establishes

There are four separate issues to track: the application identities involved in the incident, potential activity inside customer tenants, the integrity of stored backup archives, and the availability of backup and restore services. These issues interact, but none is a substitute for another.

Huntress’s original investigation reports unauthorized application authentication and, in one investigated tenant, credentials added to other applications. That observation makes a broader identity review necessary. It does not establish the same sequence in every customer, prove that all accessible data was copied, or provide a final count of affected organizations.

The practical implication is to preserve different types of evidence for different conclusions. An authentication record can support a finding that an identity obtained access. A directory audit record can support a finding that a configuration changed. A resource activity record can support a more specific finding about data operations. Missing records establish a visibility limitation unless the team can demonstrate that the relevant operation would necessarily have been captured.

Treat reports about this incident as time-stamped findings. When a vendor updates containment or restoration guidance, keep the older version with the decisions it supported. A decision that was justified yesterday may need review today without having been unreasonable when it was made. The incident record should make that distinction clear.

Do not assign an invented CVE to the event or describe a particular software flaw as the confirmed entry point. Credential abuse and software exploitation can produce similar downstream effects, but they require different evidence. The response described here addresses application identity exposure without assuming an undisclosed vulnerability mechanism.

Understand the identity before interpreting the logs

Microsoft distinguishes an application’s registration in its home tenant from the service principal representing that application inside another tenant. The application ID identifies the application, while a local object ID identifies a particular directory object. A display name is a convenience and may change. Microsoft’s application and service principal documentation explains this relationship.

For response work, record the customer tenant ID, application ID, local service principal object ID, publisher information, owner, and business purpose together. If one of those fields is missing, say so. A list containing only product names is too ambiguous for reliable comparisons, particularly after acquisitions, renaming, or a long period without administrative review.

An illustrative inventory row might describe a backup integration as application APP-DEMO, service principal SP-DEMO-CUSTOMER-A, in tenant TENANT-DEMO-A. Those labels are fictional. Their purpose is to show that the global application identity and the local tenant object are separate references. An analyst investigating another customer needs another local object record, even if the application ID is the same.

This distinction prevents a common investigation error: joining events across customers using a name and treating the result as one object history. A name match can be a discovery lead. A stable identifier, tenant context, and verified relationship are needed before it becomes evidence.

It also changes ownership questions. A customer can inspect local grants and the local service principal but may not control the vendor’s home application registration. The vendor may control a credential lifecycle that customers cannot directly observe. The customer still needs local evidence of containment and exposure. Neither side should assume the other has complete visibility.

Before making changes, capture the identifiers shown in the current directory and the exact place they were obtained. This is a small task with a large payoff: it gives later reviewers a way to distinguish a renamed object, a removed object, and a newly created object with a familiar name.

Why user MFA does not answer an application identity incident

In the OAuth client credentials flow, a confidential client authenticates with its own credential and acts using application authorization. There is no interactive user completing an MFA challenge for each request. Strong protection for employee accounts therefore does not, by itself, establish protection for this separate authentication path.

An administrator should keep the distinction narrow and accurate. This is not evidence that MFA is generally ineffective. It means that the team must identify which identity was used and which control actually evaluated that identity. A successful phishing-resistant user sign-in policy says something useful about users; it does not automatically answer questions about application credentials.

Apply the same discipline to password resets. Resetting an employee password may be necessary if that employee account is independently implicated. It does not remove a credential attached to an application object, undo a directory role assignment, or remove an unauthorized mailbox rule. Map every remediation to the object and authorization path it changes.

A useful review worksheet has three columns: the suspected access path, the control that should interrupt it, and the evidence showing that control took effect. An entry such as “application authentication, local application disabled, recorded state and time verified” is more useful than “all passwords changed.” It connects the response to the specific risk.

There is also a reporting benefit. Telling leadership that “MFA was bypassed” can imply an authentication failure the evidence does not establish. A clearer statement is that an application identity authenticated without an interactive user, and the team is reviewing the authorization granted to that identity. That language preserves the distinction between the identity system accepting a credential and a human account being compromised.

Build a tenant-by-tenant response record

Create a separate response record for every tenant in scope. Record who administers it, who can export the required logs, who owns application decisions, and who can approve restoration. Include environments reached through resellers or marketplaces. A contract path is not an evidence path; someone must be responsible for confirming that the actual tenant has been reviewed.

Use the following proposed record as an operational starting point. It is a response design, not a vendor claim about the incident.

フィールド	What to record	なぜそれが重要なのか
Tenant identity	Verified tenant ID and customer reference	Prevents evidence from being assigned to the wrong customer
Relevant applications	Application ID plus local object ID	Supports precise joins across exports
Business owner	Named internal owner and service dependency	Makes containment and recovery decisions accountable
Evidence coverage	Source, start time, end time, gaps	Defines which conclusions the evidence can support
Containment	Object changed, time, operator, verification	Distinguishes an intended action from a verified state
Findings	Observation, confidence, supporting record	Keeps leads separate from confirmed results
Recovery	Preconditions, test result, approving owner	Prevents access from returning without validation

A record can be useful before it is complete. Mark an unresolved field as unknown and assign a follow-up. Do not copy a neighboring tenant’s value to make the worksheet look finished. The purpose is to expose uncertainty early enough that someone can resolve it.

For large MSPs, maintain a summary showing which tenants need action, but preserve the individual records beneath it. Summary counts should come from explicit states such as awaiting access, evidence exported, review in progress, containment verified, and recovery approved. A single “done” field hides too much.

Prioritize tenants using evidence and consequence. Privileged grants, suspicious authentication, unexplained object changes, sensitive information, and short evidence retention can all justify earlier work. A lack of a current commercial subscription should not be treated as proof that an old application connection no longer exists. Check the directory itself.

Identify the applications using current official information

Start with the current vendor application inventory and compare it to local Enterprise applications. Match application IDs first, then record the local object IDs and names. Expand the review when evidence shows that another identity was changed or used. The original vendor inventory defines the starting set; findings determine whether the investigation needs a larger set.

Do not invent a fixed application list from a product name. Integrations can separate backup, management, and resource-specific functions. An administrator searching only for one familiar name can miss a renamed object or a different component. Keep the source date with the list used for each tenant so a later update can be reconciled deliberately.

For each match, inspect its current enabled state, permissions, role assignments, and ownership. Record evidence before making changes when doing so will not delay urgent containment. If a dangerous condition must be interrupted immediately, capture the action and the state visible afterward, then document what could not be preserved first.

Keep a second list for uncertain matches. That list might include a similar name with a different application ID, an unfamiliar publisher, or an object that an owner cannot explain. Investigate those entries without silently calling them part of the same incident. This makes the review broader without making the claims broader.

A useful completion check is to have another administrator reproduce the inventory from the identifiers rather than from the original analyst’s screenshots. If the second reviewer cannot locate the same object, resolve the discrepancy before relying on a containment conclusion. Differences can reflect an incorrect tenant, an object removed during response, or a mistaken identifier.

Preserve evidence before its limits become the investigation

Microsoft’s Entra retention reference describes default audit and sign-in retention of seven days for Free and 30 days for P1 and P2. Availability also depends on report type, licensing, and any configured export. Check the tenant’s actual coverage rather than calculating an investigation deadline from a license label alone.

Preserve raw exports, the query used, the time zone, the export time, and any pagination or row limits. A screenshot can be useful context but is a poor replacement for records that another analyst can sort and correlate. Keep the original export unchanged and work from a copy. Record any normalization performed on dates or identifiers.

When several people export evidence, give them the same coverage request and a common naming convention. For example, the file name can contain a tenant reference, source, and UTC interval without including secrets or personal data in the name itself. Store sensitive contents in the organization’s approved evidence location with appropriate access controls.

Do not assume that turning on a new logging destination reconstructs earlier activity. Separate historical evidence already available from telemetry enabled during the response. Both are useful, but they answer different questions. A new collection can help monitor containment while leaving an earlier exposure interval unresolved.

The evidence record should also describe what was not collected and why. An unavailable export, an expired interval, a missing permission, and a disabled data source are different limitations. “No evidence found” conceals those differences. “The requested interval predates available sign-in records” is a finding that tells the decision-maker exactly what remains unknown.

If an export is unexpectedly small, verify the filter, tenant, object, report category, and pagination before concluding that activity was absent. A clean-looking result can be a query problem. Have a second analyst review the collection method for the highest-consequence tenants.

Read service principal sign-ins as authentication evidence

Use the report category appropriate to the identity. Microsoft’s service principal sign-in documentation explains that these events concern nonuser authentication and that matching events may be grouped. Expand grouped entries when reconstructing a timeline; a displayed row is not necessarily one authentication event.

For each relevant record, preserve the timestamp, tenant, application identity, resource, result, source information, and correlation fields available in the export. Availability differs across data sources. Leave unavailable fields empty with a reason rather than manufacturing values to fit a preferred schema.

Separate failure from success. A failed authentication attempt can establish targeting or a blocked attempt under the observed conditions. A successful authentication record supports a stronger access concern. Neither result alone establishes which content was read. The next step depends on resource activity, permissions, and related changes.

Compare against the application’s expected operation using an actual baseline when available. The baseline should include normal resources and known maintenance activity, not only source addresses. An unusual resource combined with an unexplained privilege change deserves attention even if the address looks familiar. A new address with an approved migration record may have a benign explanation.

Document that explanation. Analysts often resolve a lead through a phone conversation and then leave no record of why it was closed. Record the owner, evidence, and time supporting the decision. Another reviewer should be able to understand why a lead was closed without relying on memory.

Avoid treating user-agent strings, addresses, or time patterns as actor identity. They can guide a search and strengthen a correlation, but attribution requires more. For this response, the useful outcome is a defensible account of access and required remediation, not a speculative name for an operator.

Reconstruct changes to identities and permissions

Authentication analysis should be paired with a review of changes. Microsoft’s Entra audit log overview describes the directory audit data used to review administrative activity. Focus on the initiating identity, target object, operation, result, and changed properties available for each event.

Build a chronological worksheet linking suspicious sign-ins to changes in credentials, roles, owners, consent, or policies. A temporal relationship is a lead rather than proof of causation. Use object identifiers and available correlation data to support the connection. Where a record cannot identify the source or the exact change, preserve that limitation.

Review approved maintenance records in parallel. A service may legitimately modify an object during installation or repair. The right question is whether the exact change was expected, authorized, and consistent with the owner’s explanation. A general statement that “the vendor does updates” is not enough to close a specific unexplained privilege change.

Give special attention to a change that creates a new access path. Removing the original identity’s permission does not remove a credential attached to another object. MITRE documents added cloud credentials under ATT&CK T1098.001. Use the technique as an investigation category, not as proof that every matching operation was malicious.

The strongest change review combines history and current state. Historical records show when a change happened and who initiated it. Current state shows whether the condition remains. Either view alone can be incomplete: history may predate current remediation, while a present-day inventory can hide a credential that existed during the exposure interval and has already been removed.

Assign an owner to every unexplained change. It should end with a supported benign explanation, a remediation record, or an explicitly unresolved risk. Do not let uncertain changes disappear into a generic incident note.

Review credentials beyond the original integration

Treat the credential review as a comparison between authorized state and observed state. Begin with applications linked by evidence, then extend according to privileges and dependencies. Management and security integrations deserve careful attention because their permissions can make an additional credential consequential.

For each object, record credential identifiers, type, available creation and expiration metadata, ownership, and the explanation for its presence. Do not retrieve or circulate secret values to prove that a credential exists. Metadata and authenticated directory records are normally the appropriate evidence for this review.

Ask the owner what created the credential, what service uses it, and what change record supports it. A long expiration date or an unfamiliar name is a reason to investigate, not a complete finding. Conversely, a friendly name does not make a credential authorized. Prefer provenance and lifecycle evidence over labels.

If the team identifies an unauthorized credential, connect removal to a verification task. Confirm the specific credential no longer appears, review whether another access path was created, and monitor relevant authentication after remediation. The precise steps depend on the object and the organization’s incident authority; this article intentionally does not provide a bulk production deletion command.

Review the effects on legitimate services as well. Removing an unauthorized credential should not require preserving it for convenience, but legitimate credentials might have similar metadata. A careful mapping of object, credential identifier, and consumer reduces avoidable outages while supporting urgent action.

A proposed evidence ledger can be compact: object ID, credential identifier, expected owner, provenance, decision, action time, and independent verification. Use a separate restricted channel for any sensitive material. The ledger should help reviewers reach the same decision without exposing usable credentials.

Keep permission review separate from credential review

A valid credential establishes an identity’s ability to authenticate. Its permissions determine what the identity can do. Review both. Rotating a credential while leaving an unjustified high-privilege grant can preserve the consequence of a future compromise. Removing a role while leaving another broad grant can also leave a significant path open.

Microsoft’s Graph app-only access guidance explains that application permissions and administrative consent are part of application access without a user. In the response record, identify the actual grants and resources rather than summarizing an integration as “read-only” from its business description.

Compare present permissions to a documented approved baseline. If no baseline exists, reconstruct the business requirement with the application owner and record the uncertainty. Do not describe that reconstructed state as proof of what existed before the incident. It is a proposed authorization decision for the future.

Review directory roles, resource permissions, ownership, and consent as distinct categories. They can have different administrative paths and different consequences. A single exported list of API permissions is not a complete inventory of every way an identity can influence the environment.

Use a decision table when several owners are involved. Each grant should have a purpose, an accountable approver, a current need, and a review date. If an owner cannot explain a privilege, escalate the decision rather than leaving the grant silently in place. The incident is an opportunity to resolve ambiguity, but that does not justify making undocumented production changes.

For each removed grant, record the expected lost function and the evidence that the change took effect. This makes the response reviewable and gives the service team a basis for testing required functionality later. The recovery process should not simply restore every old permission because a connector complains.

Investigate mailbox and resource changes with the right question

A directory investigation cannot answer every question about mail and files. Identify the workloads the application could reach and determine what resource-specific evidence is available. Relevant questions include whether forwarding changed, whether an inbox or transport rule appeared, whether mailbox access was delegated unexpectedly, and whether available records support particular file or message operations.

These are investigation categories, not a claim that each occurred in this incident. Keep the difference explicit in both the technical report and customer communications. A checklist item marked “reviewed” should include the evidence used, the interval, and the result. It should not imply that the category was observed maliciously.

Microsoft’s illicit consent investigation guidance provides useful context for reviewing application grants and exposure. The ConnectWise incident should not automatically be labeled consent phishing: misuse of an existing trusted application’s identity is a different proposition from a user approving a newly malicious application. Use the relevant investigation practices without asserting an unverified entry mechanism.

For a mailbox finding, record the affected object, before and after state if available, who initiated the change, and whether the change was authorized. For a resource access finding, record what the log actually demonstrates. A token request for a service, a successful API request, and a confirmed export of particular content are different levels of evidence.

When resource visibility is insufficient, describe the maximum access supported by permissions separately from the minimum activity confirmed by logs. Those two statements define a useful uncertainty range. They help incident owners decide whether additional investigation, notification analysis, or monitoring is necessary without presenting potential access as established exfiltration.

Keep containment work and legal assessment coordinated through the organization’s established process. The technical team should provide accurate observations and uncertainty, while authorized privacy and legal staff determine obligations. A security article cannot resolve a specific organization’s reporting duties from a generic incident description.

A containment matrix prevents premature closure

Containment should be recorded as a set of verified conditions. The following matrix is a proposed method for organizing that work. It is intentionally more specific than a single “vendor patched” status.

Condition	Evidence to seek	What the condition does not establish
Original local application disabled	Verified local state and recorded time	Earlier activity did not occur
Vendor credential action completed	Current vendor instructions and applicable confirmation	Every customer-side change has been reversed
Unapproved additional credentials removed	Object-specific before and after metadata	No other identity was changed
Unapproved privilege changes addressed	Reviewed grants and roles with verification	All data access has been reconstructed
Evidence preserved	Raw exports, coverage, and integrity record	The source logged every relevant operation
Recovery authorized	Approved prerequisites and completed tests	Historical exposure is fully resolved

Choose independent reviewers for the highest-risk conclusions. An administrator who performed a change can verify it, but a second person can catch an incorrect tenant, an incomplete filter, or a misunderstanding of the intended state. The review does not need elaborate ceremony; it needs enough independence to test the conclusion.

Keep an exception register. Some tenants will lack historical logs. Some application owners will be unavailable. Some business workflows may require an interim arrangement. Record the exception, the risk it leaves, the temporary control, the approving owner, and the date for review. Uncertainty should be managed visibly rather than erased by a green dashboard.

Avoid defining success as the absence of new alerts. Alerts depend on collection and detection. A quiet period is useful only when the team knows which access paths are covered and which events would have generated a signal. Containment confidence should come from object state, relevant authentication, change review, and verified monitoring together.

The final containment statement can be short and bounded: the listed identities are disabled in the specified tenant, the identified unauthorized changes have been removed, and the documented sources show no additional matching activity during the stated interval. That is stronger than an unqualified assurance because a reviewer can test it.

Separate backup archive integrity from recovery readiness

The vendor’s archive findings and the availability of restore operations belong in separate fields. An archive can be preserved while the normal service for accessing it is unavailable. A customer can also have a live tenant exposure even when a backup archive remains isolated. Treat these as distinct risk decisions.

For each critical workload, record the most recent verified successful recovery point, the time since it was produced, and whether the team can currently restore from it. If restore capability cannot be tested, mark it unverified. A historical job success notification is useful but is not the same as a current successful restore.

Build a temporary continuity plan around actual business requirements. Identify which information changes fastest, which operations require the shortest recovery interval, and what approved alternatives can reduce the gap. Do not assume that a retention feature, a recycle bin, and an independent backup provide equivalent protection. Evaluate each option against the specific failure or deletion scenario the business needs to survive.

If a temporary backup service is considered, review its permissions, credential model, data handling, retention, and exit process before granting access. An incident-driven rush can create another unmanaged high-privilege integration. The replacement decision should include how the organization will verify successful collection and restoration, and how temporary access will be removed afterward.

Keep the operational cost visible. During a service interruption, administrators may be unable to perform familiar restores or management tasks. Record the affected functions, responsible teams, and approved workarounds. This helps leadership allocate effort without misinterpreting every operational limitation as evidence of additional compromise.

When service returns, reconcile the interruption interval. Determine which data was collected, whether gaps remain, and whether any promised recovery point was actually achieved. The return of a green status page should start that validation, not replace it.

Recovery should require evidence at each boundary

A controlled recovery plan should define prerequisites before re-enabling application access. Include current vendor instructions, completion of local identity review, approved permissions, credential ownership, logging coverage, and a named person responsible for observing the first production activity. Different tenants may be ready at different times.

Use a small, authorized validation set where the product and the organization’s process allow it. Verify required functions with nonsensitive test data and a documented expected result. Record the actual identity, resource, time, and outcome. Do not infer successful recovery from a login alone when the requirement is backup and restoration.

Define a stop condition. An unexpected grant, unexplained authentication, missing log source, or failed restore can justify pausing the reconnect process and investigating. The stop condition should be known before the test so that operational pressure does not redefine success afterward.

Record who approved restoration and what evidence they reviewed. An approval should reference the tenant’s response record, rather than an informal message that “the vendor says it is fixed.” Vendor recovery and local readiness are related inputs to a decision; the customer remains responsible for understanding local exceptions.

For the first observation interval, compare actual application behavior with the expected baseline. Look at resources, timing, directory changes, and required functionality. If the approved recovery involved permission reductions, test that the service works within those reductions rather than allowing a broad consent request to silently restore the old access.

After initial recovery, schedule an internal follow-up through the team’s normal incident process to confirm sustained backup operation and a successful representative restore. This recommendation is not a claim that a particular vendor requires a specific testing interval. Choose the interval based on business impact, service behavior, and available evidence.

Educational lab: classify synthetic evidence without touching a tenant

The following Python demonstration uses fabricated records and performs no network requests. It does not authenticate to Microsoft, request a token, change an application, or reproduce the incident. Its purpose is to make a response distinction testable: suspicious authentication, an identity change, and a containment action should remain separate observations.

Run it locally with Python 3. The identifiers and event names belong to the example’s own simplified schema. They are not a Microsoft export format, real application identifiers, or a production detection rule.

from collections import defaultdict

records = [
    {"tenant": "LAB-A", "kind": "auth", "result": "success",
     "app": "backup-demo", "expected": False},
    {"tenant": "LAB-A", "kind": "credential_change",
     "target": "management-demo", "approved": False},
    {"tenant": "LAB-A", "kind": "disabled", "app": "backup-demo"},
    {"tenant": "LAB-B", "kind": "auth", "result": "failure",
     "app": "backup-demo", "expected": False},
    {"tenant": "LAB-B", "kind": "disabled", "app": "backup-demo"},
]

summary = defaultdict(lambda: {
    "unexpected_auth_successes": 0,
    "unexpected_auth_failures": 0,
    "unapproved_credential_changes": 0,
    "disabled_apps": set(),
})

for item in records:
    state = summary[item["tenant"]]
    if item["kind"] == "auth" and not item["expected"]:
        if item["result"] == "success":
            state["unexpected_auth_successes"] += 1
        elif item["result"] == "failure":
            state["unexpected_auth_failures"] += 1
    elif item["kind"] == "credential_change" and not item["approved"]:
        state["unapproved_credential_changes"] += 1
    elif item["kind"] == "disabled":
        state["disabled_apps"].add(item["app"])

for tenant in sorted(summary):
    state = summary[tenant]
    print(tenant)
    print("  unexpected successes:", state["unexpected_auth_successes"])
    print("  unexpected failures:", state["unexpected_auth_failures"])
    print("  changes requiring review:", state["unapproved_credential_changes"])
    print("  disabled apps:", ", ".join(sorted(state["disabled_apps"])))
    print("  data access: not determined by these records")

The expected output shows one unexpected success and one unapproved credential change for LAB-A, plus the disabled backup application. LAB-B shows a failure and a disabled application. Neither tenant receives an automatic “data stolen” or “clean” verdict. Those conclusions require evidence absent from the input.

The example deliberately retains the credential-change observation after the original application is disabled. A remediation event should not erase an earlier finding. In a real investigation, an additional record would be needed to establish that the changed object had been reviewed and, if necessary, remediated.

The classifier also keeps customers separate. A failure in LAB-B does not weaken the finding in LAB-A, and a successful action in LAB-A does not prove an outcome in LAB-B. This is the same discipline an MSP needs when producing a fleet summary.

Before adapting this idea to internal exports, define a schema mapping and validation procedure. Confirm time formats, success semantics, object identifiers, duplicate handling, missing fields, and coverage. A script that runs without error can still produce an incorrect security conclusion if its assumptions do not match the source data.

Design detections around changed trust

A durable detection strategy should look for consequential changes to trust relationships, not only for a published address. The proposed categories below are starting points for an organization’s own engineering and tuning. They are not claims of tested coverage for this incident.

A credential addition should be evaluated with the target’s privilege, owner, creation context, and expected maintenance process. A directory role assignment should be evaluated with the initiating identity and the business need. A newly granted resource permission should be evaluated with the application’s purpose and historical baseline. Combining these dimensions makes an alert explainable.

Use separate detection outcomes for discovery and escalation. A broad inventory query can identify candidates for review without paging an incident responder for every legitimate change. A narrower correlation can escalate an unexpected credential change on a privileged application when the owner cannot explain it and related authentication is present.

Document what each rule cannot observe. If resource reads are not collected, the detector cannot claim to establish the absence of data access. If the rule consumes only directory changes, it cannot discover every misuse of an unchanged permission. These limitations should appear alongside the rule’s intended finding.

Maintain exceptions as records with owners and expiration dates. An approved automation job can explain a repeating pattern, but the exception should refer to a specific object and behavior. A broad exemption for an entire vendor can hide a future deviation that matters.

Test detections with synthetic events and approved administrative activity in a separate environment. Confirm that the alert contains enough identifiers for an analyst to locate the object and understand the decision. An alert that says only “suspicious application” moves the hardest work downstream without providing evidence.

Finally, measure whether responders can close the loop. A useful detection should lead to a decision, a verified action where needed, and feedback into the baseline. Counting alert volume alone does not establish that the organization can detect or contain meaningful application misuse.

Apply workload controls only where they are supported

Microsoft’s Conditional Access for workload identities documentation states that these policies apply to supported single-tenant service principals registered in the organization. Microsoft and third-party SaaS multitenant applications are outside the documented scope, and creating or modifying the policies requires Workload Identities Premium licensing.

Do not turn a general workload security recommendation into a promise that it can directly block this vendor’s multitenant application. First identify the application’s type, ownership, and supported enforcement. Then choose controls that actually operate at that boundary. The same check should be applied to any product recommendation made during an incident.

For applications owned by the organization, evaluate credential management, constrained permissions, monitored changes, and applicable workload policies with the responsible identity team. For a vendor-owned application, ask the vendor how it protects its home identity, limits credentials, detects misuse, and communicates changes. A customer may need different compensating controls because the customer does not own the application registration.

Evaluate the response properties of each control. What can it prevent? What does it log? Who can change it? How can an administrator verify that it applies? A control description without those answers is difficult to rely on during an outage.

Keep license dependencies explicit in the implementation plan. A feature visible in documentation may be unavailable in a particular tenant or require a different entitlement. The response should provide a viable path with the capabilities actually available while documenting any gap that requires a later investment.

A useful outcome is a control map assigning each access path to a prevention mechanism, evidence source, owner, and verification method. The map should make unsupported assumptions visible. It should not imply that purchasing one identity feature eliminates the risk of every trusted integration.

Use application instance locks as a developer control

Microsoft documents application instance property locks as a way for application developers to restrict modification of sensitive service principal properties. This is relevant to application design and review. It is not a customer-side substitute for investigating an object that may already have been changed.

For an application your organization develops, ask the engineering owner which sensitive properties must remain configurable and which can be locked. Review that decision with deployment and support teams so a legitimate integration requirement is not confused with an unrestricted default. Test the resulting behavior in a nonproduction environment.

For an application owned by a vendor, request a clear explanation of the protection provided and the configuration applicable to your deployment. Record the answer with the vendor review. Avoid treating a feature name as evidence that every relevant object is protected. Verification needs an applicable configuration and a supported test or attestation.

Property restrictions also need lifecycle review. A setting appropriate at initial deployment may change when the product adds federation, changes authentication, or introduces a new integration. Make the control part of release and change review rather than a one-time security checkbox.

The investigation and the design improvement should remain separate work items. One establishes what happened and removes unauthorized state. The other reduces future opportunities for an equivalent trust change. Closing the design task cannot retroactively prove that the earlier environment was safe.

Treat every integration as a maintained access relationship

A backup connector is often reviewed when it is purchased and then left to operate for years. The incident response record should become a maintained inventory with an owner, business purpose, permission baseline, credential responsibility, data scope, and retirement condition. This is a proposed operational practice for trusted integrations generally.

Review access when a product is renamed, acquired, replaced, or no longer used. A billing change or expired contract is not an authoritative directory state. Confirm that unneeded objects, grants, and credentials have been handled through the organization’s approved retirement process, and preserve the record needed to explain later authentication attempts.

Define a minimum evidence requirement for onboarding. The organization should know how to find application authentication, how to identify permission changes, whom to contact during an incident, and how to suspend the integration. These questions are easiest to answer before the service becomes critical to daily operations.

Also define an exit test. An integration is not fully retired merely because the user interface no longer lists it. The responsible teams should verify the relevant identity and authorization state, account for retained data, and confirm that replacement services meet the required business function. The exact actions depend on the platform and contract.

For high-privilege services, make periodic review proportional to consequence. A low-impact reporting tool and a broad management integration do not need identical operational attention. Use the application’s actual permissions and dependency profile rather than the marketing category to determine review depth.

A maintained relationship also improves future incident response. The team can compare observed state to a known decision, locate the owner quickly, and understand what suspending access will break. That reduces the time spent reconstructing basic facts while important logs are approaching their retention limit.

Validate controls without recreating the intrusion

A security team can test its response capability without acquiring vendor credentials or attempting unauthorized tenant access. Define a small authorized exercise in a separate environment: create a harmless application, document its expected state, perform a benign approved configuration change, verify collection, and confirm that the review process identifies the change correctly.

The test should verify an outcome rather than merely execute a command. Did the identity inventory identify the right object? Did the event reach the expected collection? Did the detector preserve the initiating and target identities? Could another analyst distinguish the approved change from an unexplained one? Could the team record remediation and verify the final state?

Set boundaries before the exercise. Use owned identities, nonsensitive data, a clear stop condition, and explicit approval from the environment owner. Avoid granting broad privileges merely to make a demonstration dramatic. The objective is to validate the evidence and decision process with the smallest necessary access.

Teams evaluating 寡黙 for authorized security testing should apply the same evidence standard to any workflow they automate: a defined scope, observable results, reviewable artifacts, and a verified retest. Microsoft 365 connector support and the permissions required for a particular investigation should be checked separately rather than assumed from a general testing platform description.

Keep the resulting exercise report distinct from the real incident findings. A successful lab test can establish that a rule or process works under the tested conditions. It does not prove that historical production activity was captured or that a particular customer was unaffected.

Repeat the exercise when the collection pipeline, application model, or response ownership changes. The value is not repetition for its own sake. It is confirming that the parts on which the organization now relies still produce the evidence needed for a decision.

Resolve disagreements between exports before counting impact

Two exports can describe the same underlying activity differently. One may aggregate events while another preserves individual timestamps. One may use a display name captured at event time while another shows the object’s current name. Before counting affected tenants or changes, define what constitutes one observation and how duplicate records will be handled.

Create a small reconciliation sample from the most consequential findings. Compare the raw record with the normalized worksheet and the final report. Verify that tenant identifiers, object identifiers, timestamps, and outcomes survived the transformation. If an analyst corrected a field manually, keep the original value and the reason for the correction rather than overwriting the source silently.

Distinguish an unavailable field from a negative result. A missing resource field does not mean no resource was accessed. A missing actor address does not establish an internal operator. A missing change detail does not establish that the operation had no effect. These distinctions matter when different collection systems expose different parts of the same event.

Use cautious counting units in summaries. Count reviewed tenants separately from tenants with suspicious attempts, successful authentication, unexplained changes, or confirmed data operations. A tenant can appear in more than one category. The categories should not be added together as if they were disjoint victim counts. State the population the team could observe before describing a percentage.

A related issue is evidence provenance. An alert supplied by another organization can be a strong lead while still requiring local corroboration. Record the source, receipt time, identifiers, and claims. Mark which parts the tenant’s own records confirm and which remain externally reported. This preserves useful collaboration without presenting another team’s visibility as your own.

When evidence conflicts, keep both records and assign a specific resolution task. Check collection delay, aggregation, time zone conversion, permission differences, and scope before interpreting the difference as malicious interference. Some disagreements will remain unresolved. The report should describe their effect on confidence rather than choose whichever version produces a simpler narrative.

For the highest-risk findings, have a second reviewer reproduce a small number of joins from raw data. This tests the analysis method more effectively than rereading a polished report alone. The result should be a chain from source record to conclusion that an independent reviewer can follow without relying on undocumented assumptions.

Write conclusions that survive review

A strong incident conclusion states the tenant, interval, identities, evidence, observed activity, remediation, and remaining limits. It can be concise while still being exact. Avoid turning a qualified technical finding into an absolute customer assurance during the reporting process.

For example, a bounded statement could say that the reviewed exports show successful authentication by a specified identity during a stated interval, the team found one unexplained credential change, and that credential was removed with the result independently verified. The report can separately state that available resource telemetry is insufficient to determine whether particular data was read.

An unsupported statement would collapse those observations into “the attacker stole everything” or “we disabled the app, so no data was exposed.” Both exceed the evidence. The first treats permission as proof of use; the second treats containment as proof about the past.

For leadership, present the operational decisions: what is contained, what remains uncertain, which functions are unavailable, what evidence is expiring, and what conditions govern recovery. For technical reviewers, attach the identifiers and supporting records. The two versions should express the same findings at different levels of detail.

For customer-specific reports, avoid exposing another customer’s identifiers or findings. Fleet-level observations can explain why a review was expanded, but they do not belong in a customer’s evidence packet unless disclosure is authorized and necessary. Keep shared incident context separate from tenant-specific artifacts.

Preserve revisions. If a later finding changes the conclusion, record what changed and why. A traceable revision is more trustworthy than silently replacing an earlier assessment. It also helps teams learn which evidence gaps, collection delays, or assumptions made the first assessment incomplete.

Questions administrators are asking

Is this the same as a ScreenConnect vulnerability?

• This article addresses the Cloud Backup and SkyKick application identity incident. Product names under the same vendor do not establish a shared vulnerability or affected scope.
• Check the current product-specific advisory before applying a ScreenConnect patch instruction to another service.

Does a successful application sign-in prove data was stolen?

• It supports an authentication or access finding under the recorded conditions. It does not, by itself, identify the content read or prove exfiltration.
• Correlate permissions, directory changes, and available workload activity, and preserve visibility limits in the conclusion.

Do employee MFA and password resets resolve the risk?

• They address user authentication paths when applicable. Application credentials and application permissions require their own review.
• Choose each remediation according to the identity and object involved; do not use a password reset as evidence that an application credential was removed.

Are preserved backup archives the same as a safe live tenant?

• No. Stored archives and the live Microsoft 365 environment are different investigative subjects.
• Record archive findings, live tenant findings, service availability, and restore verification separately.

Can we finish once the original application is disabled?

• Confirm the disabled state, then review evidence of additional credentials, permissions, or other access changes.
• An action affecting the original connection does not establish that changes to separate objects have been remediated.

What does an empty log search tell us?

• It tells you that the specified search returned no matching records from the available source and interval.
• Verify report type, tenant, identifiers, retention, collection, filters, and pagination before drawing a broader conclusion.

When should application access be restored?

• Follow current vendor restoration guidance and complete the tenant’s documented local prerequisites.
• Require approved permissions, resolved critical findings, sufficient monitoring, and verified required functionality, including a representative restore where appropriate.

Is there a confirmed CVE or entry mechanism to test?

• The reviewed vendor update identifies compromised application identities while the original exposure mechanism remains under investigation.
• Do not invent a software exploit, production payload, or scanner signature to fill that gap. Test your own evidence collection and response controls in an authorized lab.

Close the response with a verifiable state

The strongest response outcome is a tenant record another administrator can reproduce. It identifies the relevant applications, preserves the available evidence, explains consequential changes, verifies remediation, and records what remains unknown. Recovery then adds a separate demonstration that required services work within the approved trust configuration.

Keep historical exposure, present containment, and future prevention as distinct conclusions. That discipline allows an organization to restore necessary functions without pretending that every unanswered question has disappeared. It also turns an urgent vendor incident into a lasting improvement in how trusted applications are inventoried, monitored, and retired.