Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Partner-to-partner (P2P) transfer is a critical transition point in the customer lifecycle. Changes in who administers a tenant, who can transact, and who has visibility into the customer’s digital estate can create opportunities for fraud, misuse of privileges, and operational disruption. This guidance helps Cloud Solution Provider (CSP) partners identify the most common risk areas and apply practical controls to reduce exposure, when onboarding a customer as a result of a transfer from another partner.
Transfer milestones
From a risk perspective, P2P transfers can be viewed as two major milestones. Each milestone has the potential to introduce different threats and control priorities.
- Secure onboarding - establish a relationship with the new customer: The incoming partner confirms the customer relationship, aligns on security expectations, and reduces uncertainty about who should have access and authority.
- Secure cutover - transfer assets from the outgoing partner to the incoming partner: The transfer is executed and residual access is removed, while ensuring customer assets and operations remain protected.
After the secure cutover, the customer moves into ongoing management as part of the standard customer lifecycle.
Secure onboarding - establish relationship with the new customer
This onboarding milestone is primarily about reducing uncertainty. As the partner receiving the transfer, you should treat this as a controlled onboarding event: confirm the legitimacy of the customer relationship and establish a minimum-security baseline before administrative responsibility changes.
Risk can increase when the customer’s identity or authorization isn't clearly validated, when security expectations aren’t agreed up front, or when the tenant’s current security posture is unclear.
Common risk scenarios and recommended controls:
| Risk scenario | Description | Control |
|---|---|---|
| Customer identity or authority isn't validated | The incoming partner onboards based on unverified contacts or incomplete authorization. | Validate the customer relationship and authorization. Confirm that the individuals requesting the transfer are authorized by the customer to initiate and approve administrative changes. |
| Unclear security baseline | Weak authentication practices, inconsistent privileged access controls, or legacy identities create avoidable exposure. | Set a minimum-security baseline early. Ensure strong authentication practices (such as multifactor authentication) are in place for partner and customer access paths that are used during the transition. |
| Limited understanding of the digital estate | Missing context about subscriptions, tenants, and admin paths increases the chance of blind spots after transfer. | • Perform a risk-based security review. Identify high-risk conditions (for example, excessive privileged accounts, legacy identities, weak recovery paths, or high Azure quota) and agree on remediation ownership with the customer. • Establish an initial asset and admin inventory. Maintain an actionable view of subscriptions, administrators, and support-critical dependencies so responsibilities are clear after transfer. |
| Insufficient due diligence for transaction risk | Financial exposure can rise if the incoming partner doesn’t align commercial terms and customer readiness | Apply appropriate commercial due diligence. Use risk-based checks to reduce the chance of financial exposure or avoidable service disruption. |
Minimum validation checks before moving to Milestone 2
- Customer approvals and authorized contacts are documented.
- The incoming partner understands the customer’s critical subscriptions and administrative model at a high level.
- A security baseline for identities used during the transfer is confirmed (for example, MFA where applicable).
Secure cutover - transfer assets from the outgoing partner to the incoming partner
This milestone is primarily about access removal and verification. As the partner receiving the transfer, you should treat cutover as a security-sensitive change event. So the post-transfer state matches what you and the customer expect:
- Verify the outgoing partner’s privileges are fully removed, right-size roles to least privilege
- And reconcile asset ownership and administrative responsibilities
Common risk scenarios and recommended controls
| Risk scenario | Description | Control |
|---|---|---|
| Residual access remains | Outgoing partner accounts, delegated admin privileges, or legacy security groups continue to grant administrative reach. | Verify removal of outgoing partner access. Confirm that delegated admin relationships and other privileged paths associated with the outgoing partner are removed and can’t be reused. |
| Privilege is re-established unintentionally. | Access is removed in one place but persists through alternate paths (for example, break-glass accounts, automation identities, or inherited role assignments). | Apply least privilege for the incoming partner. Limit roles to what’s required for customer support, and avoid persistent high-privilege assignments where alternatives exist. |
| Unauthorized transactions during the transition window | Changes to subscriptions, licensing, or billing occur without clear customer approval and auditability. | Maintain auditability of approvals and changes. To support investigation and compliance needs, keep records of customer approvals and administrative changes made during the transition. |
| Inventory mismatch after transfer | The incoming partner lacks a complete view of assets and dependencies, leading to support gaps and configuration drift. | Reconcile assets and administrative ownership. Validate that subscriptions, licenses, and support responsibilities match the expected post-transfer state and are documented. |
| Post-transfer monitoring gaps | Unusual activity isn’t detected early, delaying response to compromise or misuse. | Monitor for anomalous activity. Increase monitoring for high-risk actions during and immediately after the transfer window and ensure escalation paths are in place. |
Minimum validation checks to close the transfer
- Outgoing partner access paths are verified as removed
- Asset/subscription inventory is reconciled to the post-transfer state
- A post-transfer review confirms least privilege and an agreed monitoring plan
- Azure quota is aligned to customer business needs
Additional resources
- For information about best practices to follow after a customer transfer, see: Manage customer accounts and billing