SOAR API migration moves to March 31, 2027; IAM and Remote Agents still need November action

Which deadlines move, and which stay in November?

Google Cloud's October 12 release note extends SOAR API migration to Chronicle API from November 30, 2026 to March 31, 2027. The same announcement appears under Google SecOps and SOAR product categories. It is one deadline change, not two releases.

The current overview still requires the Stage 2 transition to IAM roles by November 30, 2026, and says legacy Remote Agents stop working after that date. Legacy APIs and API Keys last until March 31, 2027; the old webhook domain also has a March 31 deadline. Keep both dates in the calendar.

The guidance covers the relevant migration for unified Google SecOps and standalone SOAR customers, not every Google Cloud API. It specifies dates without a universal shutdown hour or timezone. Do not assume US or local midnight, or leave implementation until the last day.

Confirm Stage 1, then create four checklists

Stage 1 moves infrastructure and, for standalone SOAR customers, login authentication. Stage 2 covers IAM, APIs, webhooks and Remote Agent authentication. The overview requires Stage 1 to finish first; the extended API deadline does not remove that prerequisite.

In SOAR Settings > License Management, Google.com after the system version confirms Stage 1. Google.com together with CloudIAM Enabled confirms SOAR permissions have moved to IAM. Neither label proves every script or webhook has been migrated.

For example, a team maintaining a custom API script, a webhook and two Remote Agents should track API calls, webhook URLs, IAM bindings and Agent authentication separately. Assign an owner, record old and target methods, and capture validation results. This is a planning example, not a customer migration performed by PuppyIP.

Change the endpoint, identity and data model

The API guide applies to integrations, custom scripts and custom actions calling SOAR programmatically. Map each old method to its new endpoint and review field and model changes. The resource-based API structure makes this more than a domain replacement.

Chronicle supports regional service endpoints only. Select service_endpoint, project_id, location and instance_id for the actual instance, then check whether the method uses v1alpha, v1beta or v1. The guide lists US, EU and other regions; an overseas team should not automatically copy a US example.

Ordinary legacy API token authentication moves to OAuth 2.0 with Google Cloud IAM permissions. Service accounts or workload identities also need mapping in SOAR Settings > Advanced > Group Mapping to the relevant identity, SOC roles and environments. Obtaining a token does not establish permission to perform the operation.

Validate applicable custom or commercial integration changes in a staging integration before production. Check responses, fields, permissions and actual outcomes for every migrated function, rather than HTTP success alone. Custom applications should use their own isolated validation process.

Webhooks and Remote Agents need different authentication plans

Update webhook client targets from siemplify-soar.com to the appropriate googleapis.com endpoint and new request format before March 31, 2027. The overview says webhook authentication remains unchanged, using the API key created with the webhook. Do not apply the ordinary API OAuth rule to it.

Remote Agent migration changes authentication infrastructure and does not itself require replacing Agent instances or hosts. Follow its guide for version and authentication upgrades. It currently requires at least version 2.6.2 and a separate service account for each Agent to avoid exhausting individual quotas through sharing.

The Agent guide also points to keyless Workload Identity Federation. If your chosen setup uses a JSON key file, protect it under your organisation's credential-management policy. Never paste real keys, private webhook URLs or instance credentials into public examples.

Which legacy permission settings should remain?

Permission migration needs corresponding identities in Google Cloud console and SOAR, plus the appropriate Cloud Identity or Workforce Identity Federation group mapping. Unified customers also need the SIEM-side IAM prerequisites. Use the official role requirements and your organisation's access policy.

The overview updated October 12 says IAM manages permissions after migration: stop editing the legacy Permissions page and retain Permission Group assignments in Group Mapping for old-API compatibility. Moving to IAM is not a reason to delete mappings still needed by that compatibility path.

The documents differ here: the October 9 IAM guide still says the old column disappears November 30; the October 12 overview says March 31. Both say to keep its assignments. Plan from the newer overview and confirm instance behaviour with your Google representative before any cleanup.

What should you change in the plan today?

Keep November IAM and Remote Agent work on schedule, and update the API and webhook dates separately. Leave room for validation, rollback and observation. More migration time does not mean your integration already supports the new API.

Then check endpoint, identity and data-model inventories, recording the region, actual permissions and validation outcomes. If Stage 1 remains pending, review the product notification and contact your Google representative. Its downtime arrangements differ by customer type, so the overall migration is not universally interruption-free.

The announcement introduces no pricing change or expanded regional eligibility. Contracts, service availability and implementation windows still depend on the actual account. This article reviews public guidance; PuppyIP has performed no account migration or success-rate measurement.