Most security operations teams outgrow the “one connector, one account” model quickly. Production and non-production environments split, regions acquire their own tenants, and an MSSP may need to watch multiple customers without multiplying its ingestion plumbing.
Microsoft’s September 14, 2026 Public Preview: Multi-account support for Microsoft Sentinel codeless connectors introduces a cleaner pattern. A single connector built on the Codeless Connector Framework (CCF) can expose multiple, independently deployable connections in the same Sentinel workspace, each visible in one unified list.
The operating model in one view
| Capability | What the preview provides | Why the SOC should care |
|---|---|---|
| Unified connections list | Every account appears as a labeled row with identifying metadata such as account name, tenant ID, or environment. | Analysts can see coverage and ownership without hunting through duplicate connector instances. |
| Add connection | A guided form adds another source without disturbing existing connections. | New regions, subsidiaries, or customers can be onboarded through a repeatable operating path. |
| Independent lifecycle | Each connection can be deployed, edited, or deleted on its own. | A retired account does not have to take healthy sources offline. |
| Shared ingestion | Connections use the same data collection rule, endpoint, and destination table. | The design avoids multiplying ingestion infrastructure as account count grows. |
Where it fits
Microsoft calls out six practical use cases:
- Multiple accounts for one independent software vendor.
- Regional accounts that need a common SOC view.
- Developer and QA environments that should share a controlled analytics plane.
- Pre-production cloud environments that need the same detection coverage as production.
- Managed security service providers watching many customers.
- Multiple customers streaming logs into a shared Sentinel instance.
The pattern is especially useful after an acquisition or organizational split, when the security team needs consistent detections before every identity and application boundary has been rationalized. It is not a shortcut around tenant permissions: each account still needs its own authorization and accountable owner.
What the architecture actually creates
Under the hood, Microsoft describes a shared connector definition for the user interface and shared ingestion resources: the data collection rule, data collection endpoint, and destination table. Each connection creates one lightweight data connector resource with a unique name and metadata that identifies it in the grid.
That distinction matters for design reviews. The table and analytics layer are shared, but the source connection is not an anonymous checkbox. Document the source account, owner, authentication method, environment, expected event volume, and retirement date for every row in the list.
A practical SOC pilot
1. Choose a connector with visible preview support
Microsoft’s “get started” guidance tells security professionals to look for a connections list and an Add connection action. Do not assume that every existing CCF connector supports the pattern yet; public preview availability is connector-specific.
2. Pilot two accounts with different risk profiles
Use one production source and one non-production or regional source. The test should prove that an analyst can distinguish them in the list, that the credentials and permissions are isolated, and that a change to one connection does not interrupt the other.
3. Validate detection and investigation behavior
| Control | Question to answer | Evidence to keep |
|---|---|---|
| Naming and labels | Can an analyst identify the account, tenant, region, and environment from the connector row and event data? | Naming convention, sample records, and screenshots or exported configuration. |
| Authentication | Are credentials, service principals, and delegated permissions owned and rotated per source account? | Permission map, secret owner, rotation record, and least-privilege review. |
| Lifecycle | Can the team add, edit, and remove one connection without changing healthy rows? | Change ticket, before/after connection list, and ingestion health. |
| Analytics | Do rules, workbooks, playbooks, and incident views preserve the source-account context? | Test alert, incident timeline, entity mapping, and analyst sign-off. |
| Scale and cost | Does shared ingestion behave predictably as event volume and retention grow? | Daily volume, latency, table retention, and cost baseline. |
4. Treat preview as a change-controlled service
Preview features deserve a narrower blast radius and a documented exit. Define who can add a connection, which environments may use the feature, how a broken source is disabled, and how the SOC will revert to separate connector instances if the preview behavior changes.
Governance guardrails for shared workspaces
- Separate coverage from access: a shared destination table does not mean every analyst should administer every source account. Use Sentinel, Azure, and source-platform RBAC deliberately.
- Preserve account context: carry source identifiers into workbooks, analytic rules, incident triage, and reporting so a consolidated table does not erase boundaries.
- Set volume expectations: compare ingestion, retention, and query costs before and after the second connection. Shared plumbing is not free plumbing.
- Keep ownership explicit: every connection needs a business owner, technical owner, credential owner, and review date.
- Plan the delete path: test source retirement and credential revocation independently so a decommissioned account cannot silently keep sending data.
What ISVs and MSSPs should know
Microsoft recommends that new CCF connectors support multi-account where appropriate and points ISVs to its multi-account CCF documentation for the walkthrough, annotated JSON, and authoring checklist. If a connector needs engineering help, Microsoft directs partners to the App Assure intake path.
For an MSSP, the business case is operational consistency: the SOC can standardize detections and investigation workflows while preserving a connection row for each customer or environment. The security case is accountability: each row still needs a clear authorization boundary and a customer-specific escalation path.
Frequently asked questions
What does multi-account support change in Sentinel? One CCF connector can expose multiple independent connections in one workspace, each with its own lifecycle and identifying metadata.
Does each connection need separate ingestion plumbing? No. Microsoft describes shared connector and ingestion resources with a lightweight connector resource per source connection.
Can every Sentinel connector use the preview? No. Confirm that the connector exposes the connections list and Add connection experience before planning a migration.
What is the first pilot? Add one production and one non-production or regional connection, then prove independent lifecycle, source labeling, detections, permissions, and cost behavior.
Need a multi-tenant SOC operating model?
Accred Consulting can map Sentinel connectors across tenants and environments, design the account and RBAC model, and run a measured pilot with detection and cost evidence.
Plan a Security Operations Review