Multi-cloud provisioning has two layers. The first is infrastructure: creating compute, storage and networks across more than one cloud provider. The second is identity: creating, updating and removing the user accounts and groups that reach those clouds and the SaaS apps around them. Infrastructure tooling gets most of the attention. Identity is where most teams lose control.
This guide focuses on the identity layer. It explains why manual account management fails across several platforms, how SCIM 2.0 automates it, and how to roll it out when Google Workspace is your source directory.
TL;DR
- Multi-cloud is the norm: 89% of organizations report a multi-cloud strategy in the 2025 Flexera State of the Cloud Report. Every added platform adds another set of accounts to manage.
- Under the shared responsibility model, you keep responsibility for user access and identity, not the cloud provider.
- SCIM 2.0 is the standard protocol for automated provisioning. It creates, updates and removes users and groups through an API instead of by hand.
- Plan for group drift, long-lived tokens and missing audit trails before you go live.
- If Google Workspace is your directory, AnySCIM syncs users and groups to any SCIM 2.0 app with read-only access and audit logging.
Table of Contents
- What multi-cloud provisioning means for identity teams
- Why identity is the weak point of multi-cloud
- How SCIM 2.0 automates provisioning
- Manual, scripted and managed provisioning compared
- Roll out multi-cloud identity provisioning in six steps
- Pitfalls that break provisioning in production
- Our perspective
- Automating the Google Workspace side with AnySCIM
- A reconciliation routine you can start this week
- Is multi-cloud safe?
- FAQ
- Sources
What multi-cloud provisioning means for identity teams
NIST defines multi-cloud as the use of two or more cloud service providers. In practice, an IT team rarely sees it as an architecture diagram. It sees it as a growing list of consoles, each with its own user list, its own role model and its own offboarding steps.
Provisioning in this context covers four events:
- Create: a new hire gets accounts in the apps and platforms they need.
- Update: a name, title, department or manager change reaches every connected system.
- Group change: a team move adds or removes group memberships, which usually drive permissions.
- Deactivate or delete: a leaver loses access everywhere, quickly.
When one person does these four things by hand in five or ten systems, errors are certain. Someone is missed in one console. A contractor keeps access for weeks. A title change never reaches the app that uses it for role assignment.
Why identity is the weak point of multi-cloud
The scale of multi-cloud adoption explains why this problem is common. The 2025 Flexera report states that only 12% of surveyed organizations rely on a single public cloud provider, and that 70% of respondents use a hybrid approach with at least one public and one private cloud.
Security guidance points to the same weakness. In August 2026, NIST identified 23 security challenges in multi-cloud environments, grouped under identity and access management, vulnerability management, incident response and data protection. Two issues named in that coverage are inconsistent MFA implementation and fragmented visibility across provider frameworks.
The Canadian Centre for Cyber Security makes the responsibility point directly. Its cloud security risk management guidance explains that cloud use changes who is responsible for implementing security controls. In the usual split, the provider runs the infrastructure and the customer remains accountable for identity, access and data. That means the offboarding gap in your tenth application is your problem, not the vendor's.
Visibility deficits
Each provider reports differently. One exports CSV, another offers an API, a third shows a web page. Without one source of truth for who should have access, security teams cannot answer a simple question: which accounts exist that should not?
Centralizing identity provisioning gives you that source of truth. It also means a revocation action, such as disabling a departed employee, can reach every connected system from one change in the directory.
How SCIM 2.0 automates provisioning
SCIM (System for Cross-domain Identity Management) is an open standard for exchanging user identity information between identity domains and IT systems. The SCIM project site lists it as published by the IETF as RFC 7642, RFC 7643 and RFC 7644. It defines a common schema for users and groups and a REST protocol for managing them.
The model is simple:
- A source (your identity provider or directory) holds the authoritative list of users and groups.
- A SCIM client reads that list and sends changes.
- Each target application exposes a SCIM 2.0 endpoint, usually a base URL such as
https://app.example.com/scim/v2, and accepts requests authenticated with a token. - The client calls standard operations: create a user, patch an attribute, add a member to a group, deactivate a user.
Microsoft's documentation on how provisioning works in Entra ID describes the same lifecycle: creating identities and roles in cloud applications, maintaining them, and removing them when access is no longer needed.
What a solid SCIM setup supports
Microsoft's guidance for multi-tenant provisioning apps lists several traits of a robust SCIM implementation:
- Support for both soft deletes (deactivation) and hard deletes.
- Schema discovery, so clients can learn which attributes an app supports.
- Capacity of at least 25 requests per second per tenant, to avoid provisioning delays.
- HTTPS with TLS 1.2 for all communication between the identity provider and the application.
When you evaluate a target app, check these points before you plan the rollout. An app with no group support or no deactivation endpoint limits what automation can do for you.
Manual, scripted and managed provisioning compared
Teams usually move through three stages. The table compares them on the criteria that matter for multi-cloud identity.
| Criterion | Manual admin work | Custom scripts | Managed SCIM sync |
|---|---|---|---|
| Time to add an app | Minutes per user, forever | Days to weeks of development | Typically a short setup per app |
| Offboarding speed | Depends on who remembers | Depends on the schedule | Driven by the directory change |
| Maintenance | None, but high labor | API changes break scripts | Handled by the service |
| Audit trail | Tickets, if anyone files them | Whatever you log yourself | Built-in logs |
| Risk of drift | High | Medium | Low, with checks |
| Credential exposure | Admin passwords shared | Tokens stored in code or CI | Tokens held in one managed place |
Scripts feel cheap until the person who wrote them leaves. Each vendor's API quirks become a maintenance item, and a failed run often goes unnoticed until an auditor asks about it.
Roll out multi-cloud identity provisioning in six steps
1. Inventory your applications and their SCIM support
List every cloud platform and SaaS app that holds user accounts. For each, record whether it supports SCIM 2.0, whether it supports groups, and who owns it. Apps without SCIM need a documented manual process, and you should flag them as risks.
2. Choose one source of truth
Pick the directory that decides who exists and who belongs to which group. For many organizations this is Google Workspace. Clean it first: remove stale accounts, fix inconsistent department and title values, and make group names follow one convention. Provisioning copies whatever is in the source, including its errors.
3. Define attribute and group mapping
Decide which directory attributes map to which SCIM attributes in each app. Typical fields are userName, emails, name.givenName, name.familyName, title and active. Then decide which groups sync. Sync only the groups an app needs to assign permissions, not the full directory tree.
4. Generate credentials and store them safely
Each target app issues a SCIM base URL and a token. Treat that token as a privileged credential. Security guidance in Microsoft's provisioning requirements for the Entra App Gallery recommends moving away from long-lived tokens toward OAuth-based authentication where the app supports it, and keeping credentials in a dedicated vault such as Azure Key Vault. For high-security environments, it also advises treating the provisioning server as a Tier 0 asset, because whoever controls it can change access for every connected app.
5. Run a dry run, then a pilot
Before any write reaches a production app, preview the changes: which users would be created, updated or deactivated. Fix mapping errors in the preview. Then enable sync for a pilot group of 10 to 20 users and confirm the results in the target app.
6. Reconcile, then go wide
After the pilot, compare the app's user and group lists against the directory. Only then extend to the whole organization, one app at a time. Keep a recurring reconciliation, covered below.
Pitfalls that break provisioning in production
Group synchronization drift
User records usually sync cleanly. Groups cause the trouble. Membership updates can conflict when naming conventions differ, for example an app that identifies groups by GUID while the directory uses display names. A removal event that never propagates leaves someone in a group they should have left. The QPulse coverage of the NIST findings recommends a baseline consistency check after the first configuration, so the app's access control lists match the primary directory.
Confusing provisioning with access governance
Creating an account is not the same as granting the right access. The Canadian Centre for Cyber Security guidance places accountability for verifying that provisioned identities have appropriate permissions on the customer. Build an audit-log reconciliation: periodically compare SCIM-driven account changes against HR-driven lifecycle events such as hires, transfers and terminations. Any account change with no matching HR event needs an explanation.
Long-lived tokens
A token that never expires and sits in a shared document is an open door. Rotate tokens on a schedule, restrict who can view them, and revoke them when an admin leaves.
Write access you do not need
If the sync tool can modify your directory, a bug or a compromised credential can modify your directory. For a one-way flow from directory to apps, read-only access is enough. Choose tools that ask for no more than that.
Rate limits and delays
Large initial syncs can hit app-side rate limits. Stage the first run, and watch for retry and error entries in your logs.
Our perspective
We build AnySCIM around one observation: most teams do not struggle to decide that they need provisioning. They struggle with the cost of connecting each new application. Every vendor has a slightly different SCIM implementation, and every connection has traditionally meant either a script or a ticket to a specialist.
For a Google Workspace organization, we think three design choices matter most.
- Read-only access to Google Workspace. Provisioning is a one-way flow. The tool should read users and groups and never write back. This limits the damage if something goes wrong and makes the security review shorter.
- Audit logs you can export. Compliance teams need to show what changed, when, and in which app. Logs that you can export to your own systems support the reconciliation process described above.
- No scripts to maintain. Preconfigured templates for common vendors and support for custom SCIM endpoints mean a new app is a configuration task, not a development project. Our target is a connection in under an hour.
We also advise running a dry run before every new integration and treating the first sync as a test, not a launch. The point of automation is that offboarding becomes a side effect of one change in the directory. That only works if you have verified the mapping first.
— Nicolas
Automating the Google Workspace side with AnySCIM
If Google Workspace is your source directory, AnySCIM synchronizes users and groups to any SCIM 2.0 compatible platform. It covers the steps above in one service:
- Real-time syncing, so a departure in Google Workspace reaches connected apps without waiting for a manual task.
- Read-only access to Google Workspace.
- Detailed audit logging.
- Customizable group and attribute mapping.
- Preconfigured integration templates, and support for custom SCIM endpoints without scripts.
Plans are tiered by the number of users in the managed directory and organization size. The Startup plan costs $49.99 per month or $249.99 per year. The Scale plan costs $199.99 per month or $999.99 per year. Enterprise pricing is not published. You can compare the tiers on the AnySCIM pricing page, and every subscription starts with a 14-day free trial.
A reconciliation routine you can start this week
Automation reduces manual work. It does not remove the need to check. A lightweight routine covers most of the risk:
- Weekly: review sync errors and failed operations in the logs.
- Monthly: compare the user count in each connected app against the directory, and list accounts that exist in the app but not in the directory.
- Quarterly: compare group membership for privileged groups, such as admins, finance and production access, between the directory and each app.
- After every HR termination batch: confirm that deactivations appear in the logs for each connected app.
- Twice a year: rotate SCIM tokens and review who can see them.
Write each check down with an owner. A control that nobody owns is the first to lapse.
Is multi-cloud safe?
Safe enough, if you manage identity as a first-class control. The NIST challenges listed earlier are manageable, and several of them, including inconsistent MFA and fragmented visibility, come down to how consistently identity is handled. Provisioning from a single directory, applying the same lifecycle rules everywhere, and keeping audit logs are the practical answer.
FAQ
What is the difference between multi-cloud provisioning and user provisioning?
Multi-cloud provisioning in the infrastructure sense means creating resources such as servers and storage across several cloud providers. User provisioning means creating and managing the accounts that access those resources and the apps built on them. Teams need both, and they use different tools. This article covers the identity side.
Do all cloud apps support SCIM 2.0?
No. Support varies by vendor and often by pricing tier, and some apps support users but not groups. Check each vendor's documentation before you plan a rollout. For apps with a custom or less common SCIM endpoint, use a tool that lets you configure the endpoint without writing scripts.
Can Google Workspace be the source for SCIM provisioning?
Yes. Many organizations use Google Workspace as their directory but lack a native way to push users and groups to third-party SCIM endpoints. A service such as AnySCIM reads users and groups from Google Workspace and syncs them to SCIM 2.0 apps.
How fast should offboarding happen across clouds?
As fast as the directory change itself. Event-driven or near-real-time sync removes the delay of scheduled manual tasks. Your own policy should set the target, and your audit logs should prove you met it for each app.
What should I log for compliance?
Log every create, update, group change and deactivation with a timestamp, the target app and the result. Keep the logs exportable so you can reconcile them against HR records. Retention periods depend on your regulator and your own policy.
Sources
- Flexera 2025 State of the Cloud Report
- NIST Identifies 23 Security Challenges in Multi-Cloud Environments (QPulse)
- Cloud security risk management (ITSM.50.062), Canadian Centre for Cyber Security
- SCIM: System for Cross-domain Identity Management
- Understand how application provisioning works in Microsoft Entra ID
- Provisioning requirements for multi-tenant apps, Microsoft Learn
- User provisioning requirements for Microsoft Entra App Gallery