Your cloud provider's engineers are privileged identities in your environment, and most organisations never decide when they may touch customer data, who approves it, or where the evidence lands. Regulators, sovereignty programmes and auditors increasingly ask exactly that question. This guide explains the native controls that govern provider staff access on Microsoft Azure and Microsoft 365 (Customer Lockbox), Google Cloud (Access Transparency, Access Approval and Key Access Justifications) and AWS (the AWS Support service-linked role and the Nitro System's no-operator-access design). It covers who can approve, how long requests and grants last, what each control does not cover, and how to log and alert on provider access. It is written for cloud security architects, IAM owners and compliance leads in regulated sectors.
Key takeaways
- Treat provider operators as third-party privileged users. They sit outside your identity provider, so the only levers you have are approval workflows, provider logs, encryption keys you control and the contract.
- Every control has written exclusions. Azure Customer Lockbox does not fire for break-glass outages, incidental exposure or legal demands; Google Access Transparency produces no log for legally prohibited notification or for access you granted through IAM.
- Approvers must exist before the request. Azure only honours Lockbox approver role assignments that predate the request, and PIM-eligible Owners must already be active, so a missing approver means an expired request and a stalled support case.
- Approval adds time to support. Google states that Customer Care response times increase by the time spent waiting for your approval; Microsoft 365 requests expire after 12 hours and Azure requests after 4 days.
- Keys are the strongest backstop. Customer-managed keys, and on Google Cloud Key Access Justifications with an external key manager, let you refuse cryptographic access even where an approval workflow does not apply.
How identity and access work for provider operators
Provider staff do not sign in through your tenant. Their access is brokered by the provider's internal just-in-time (JIT) and privileged access systems, which you cannot see or configure. What you can configure is a customer-facing control point layered on top. Microsoft describes the Azure flow clearly: a support engineer who cannot resolve a ticket with standard tooling requests elevated permissions through a JIT access service, which evaluates resource scope, identity isolation or MFA and permission level, and may need internal Microsoft approval. Only when direct customer data access is needed does a Customer Lockbox request get created in the Customer Notified state.
The provider models differ in a way that shapes your design:
| Provider | Visibility control | Approval control | Key-based control | Design stance |
|---|---|---|---|---|
| Microsoft Azure | Activity Log and Microsoft Entra audit log entries for Lockbox requests | Customer Lockbox for Microsoft Azure (support plan Developer or above) | Customer-managed keys (recommended by Microsoft for incidental exposure cases) | Customer approves data access during support cases |
| Microsoft 365 | Unified audit log: Set-AccessToCustomerDataRequest and actions by "Microsoft Operator" | Customer Lockbox (E5 or G5, or compliance add-on) | Customer Key (separate feature) | Customer approves engineer access, maximum 4 hours |
| Google Cloud | Access Transparency logs with justification codes and accessor location | Access Approval at project, folder or organisation level | Key Access Justifications on Cloud KMS, Cloud HSM and Cloud EKM keys (Assured Workloads) | Log every access, optionally approve, optionally refuse at the key |
| AWS | CloudTrail records API calls made through AWSServiceRoleForSupport | No customer approval workflow equivalent to Lockbox for support staff | KMS key policies and external key stores | Technical prohibition: no operator access to EC2 Nitro hosts |
AWS takes a different approach. Its Nitro System whitepaper states that no system or person can log in to EC2 Nitro hosts, access instance memory, or access customer data on local encrypted instance storage or encrypted EBS volumes, and that operators use only a limited set of authenticated, logged administrative APIs that give no access to customer data. When a problem cannot be debugged in place, AWS reproduces it with the customer on non-production debugging hardware. That claim is scoped to EC2 Nitro hosts: assess managed services separately. For the wider split of duties, see the Shared Responsibility Models Guide.
Admin roles and privileged access
The approver role is itself a high-value privilege: whoever holds it can let a provider engineer read production data. Scope it as tightly as any production administrator.
| Platform | Who can enable | Who can approve | Request lifetime | Access lifetime |
|---|---|---|---|---|
| Azure Customer Lockbox | Global Administrator, in the Administration module | Subscription scope: Owner or Azure Customer Lockbox Approver for Subscription. Tenant scope: Global Administrator | 4 days, then automatic expiry with no access | Duration stated in the request details |
| Microsoft 365 Customer Lockbox | Settings > Org Settings > Security & Privacy > Require approval for all data access requests | Customer Lockbox access approver role; Global Administrators can also approve and are notified | 12 hours | Up to 4 hours, revoked automatically |
| Google Access Approval | roles/accessapproval.configEditor (settings); Access Transparency must be on first | roles/accessapproval.approver (approve, dismiss, invalidate) | Requests can be dismissed, revoked or expire; historical records kept | Approved access can be invalidated at any time |
| Google Access Transparency | Verified by a principal with roles/axt.admin at organisation level | Not applicable (visibility only) | Not applicable | Not applicable |
- Use the dedicated role: on Azure assign Azure Customer Lockbox Approver for Subscription to named approvers rather than relying on Owners. Management group scope assignments are not supported, so assign per subscription, ideally through infrastructure as code.
- Account for PIM: Microsoft states that a PIM-eligible Owner must activate the role before the Lockbox request is initiated. If your only approvers are eligible, nobody can approve. Keep at least two permanently assigned dedicated approvers per in-scope subscription, or use the dedicated approver role, which carries no resource rights. See the Privileged Identity Management (PIM) Guide.
- Separate the invalidator: on Google Cloud, roles/accessapproval.invalidator can revoke previously approved requests without approving new ones. Give it to the security operations on-call team so they can stop access during an investigation.
- Protect the settings: whoever holds roles/accessapproval.configEditor can change enrolment or the signing key. Treat it like an organisation policy administrator role and alert on changes.
Integrations, API tokens and service accounts
Provider access paths often run through non-human identities, and some of them you created yourself.
- AWS Support service-linked role: AWSServiceRoleForSupport carries the AWS managed policy AWSSupportServiceRolePolicy, which AWS Support updates about once a month to add permissions for new services. It generally cannot be deleted; AWS Organizations customers on Enterprise Support can ask their Technical Account Manager to delete it, which restricts what Support engineers can do. All AWS Support API calls through the role appear in CloudTrail, so build a CloudTrail query on that role's session activity. See the AWS CloudTrail Guide.
- Access you grant through IAM: Google's exclusions say that if you give Google personnel access through your IAM policy, the activity appears in Cloud Audit Logs instead of Access Transparency. The same principle applies everywhere: a support engineer added as a guest, a shared account or a role trust policy to a provider account bypasses Lockbox-style controls entirely. Inventory such grants and give them expiry dates.
- Service principals as approvers: Azure supports alternate email notifications so Lockbox emails can reach a different address, which Microsoft notes is useful when a service principal is the approver. If you automate approval, the automation identity becomes the control: restrict it to rules such as "approve only when the linked service request ID matches an open ticket raised by our team", and never blanket approval.
- Access Approval signing keys: approvals are signed with a Google-managed key by default. You can instead use an asymmetric Cloud KMS key or a Cloud EKM key. With a custom key, Google states that requests are processed only if their justification is permitted by the key's Key Access Justifications policy.
- Notification channels: Access Approval notifies by preconfigured email or Pub/Sub message. Route Pub/Sub into your ticketing or SOAR tool rather than a personal inbox, and monitor that the subscription still has a consumer.
For the key management side of this decision, see the Cloud Customer-Managed Keys and BYOK/HYOK Decision Guide.
What the controls do not cover
Read the exclusions before you tell an auditor that provider access is "approved". These are stated by the providers themselves.
| Control | Documented exclusion | Compensating measure |
|---|---|---|
| Azure Customer Lockbox | Emergency break-glass scenarios such as outages or security and abuse incidents | Contractual notification clause; review provider incident reports |
| Azure Customer Lockbox | Inadvertent exposure during platform troubleshooting, for example a packet capture | Customer-managed keys and encryption in transit |
| Azure Customer Lockbox | External legal demands such as government requests | Legal review of provider transparency reporting; key control outside the provider |
| Google Access Transparency | Google legally prohibited from notifying you | External key manager with Key Access Justifications where the control package supports it |
| Google Access Transparency | Access you granted through IAM; non-customer data such as aggregate queries; public resource identifiers (project IDs, bucket and VM names); standard automated systems | Cloud Audit Logs for IAM-granted access; avoid sensitive data in resource names |
| Google Access Approval | Access Transparency exclusions; automatic approval for time-sensitive outages (logged as auto approved) | Auto-approval is disabled for EU Data Boundary with Access Justifications and Sovereign Controls by Partners |
| Google Key Access Justifications | Only covers the transition from data at rest to data in use; Compute Engine Local SSD, automatic restart and machine image operations are exempt | Workload design that avoids exempt features for the most sensitive data |
The practical point: approval workflows govern routine support. Key control and contract terms govern everything else. For the sovereignty context, see the Assured Workloads and Sovereign Controls Guide and the Data Sovereignty and Residency Guide.
Logging and detection
Provider access logs are only useful if they reach your SIEM and someone reviews them. The table lists where each record lands.
| Platform | Where to look | Event or filter |
|---|---|---|
| Azure, subscription scope | Subscription Activity Log | Operation names Create Lockbox Request, Approve Lockbox Request, Deny Lockbox Request, Lockbox Request Expiry |
| Azure, tenant scope | Microsoft Entra audit log | Service = Access Reviews; Activity = Create request, Request approved, Request denied |
| Microsoft 365 | Unified audit log | Operation Set-AccessToCustomerDataRequest (ApprovalDecision Deny for denials); user "Microsoft Operator" for engineer actions |
| Google Cloud | Cloud Logging | logName ending cloudaudit.googleapis.com%2Faccess_transparency; fields reason.type, principalPhysicalLocationCountry, principalEmployingEntity, accessApprovals |
| Google Cloud keys | Cloud KMS audit logs | Key Access Justifications codes on cryptographic operations |
| AWS | CloudTrail | Calls made through AWSServiceRoleForSupport |
Microsoft notes that the History tab in the Azure Lockbox portal has been removed, so the Activity Log and Entra audit log are now the record. Export both to long-term storage, because default retention may be shorter than your audit period. See the Cloud Logging and Audit Trail Guide.
Useful detections:
- Access with no ticket: Access Transparency entries with reason.type CUSTOMER_INITIATED_SUPPORT whose reason.detail case number does not match an open case you raised.
- Unexpected justifications: GOOGLE_INITIATED_REVIEW (security, fraud, abuse or compliance) and THIRD_PARTY_DATA_REQUEST (legal process) should page the security and legal leads, not sit in a dashboard.
- Location drift: principalPhysicalLocationCountry outside the countries your data residency commitments allow.
- Auto-approved requests: any Access Approval request in the auto approved state, which signals a provider outage response.
- Configuration change: changes to Access Approval settings, disabling of Access Transparency (Google notes the Access Approval UI may become unavailable), or removal of Lockbox approver assignments.
- Expired requests: Lockbox Request Expiry events usually mean an approver gap, not a security win.
Metrics that show the programme is working:
- Percentage of provider data access events correlated to a customer-raised support case.
- Median time from Lockbox or Access Approval notification to decision, against the 12-hour and 4-day expiry windows.
- Number of in-scope subscriptions or projects with at least two valid standing approvers.
- Count of provider accesses with non-support justification codes per quarter, each with a recorded review.
- Number of standing IAM grants to provider personnel or provider-owned accounts, target zero without expiry.
Hardening baseline
Roll out in phases. Approval controls can block urgent support, so test the process before you depend on it.
- Decide scope: list workloads where provider access to data is a regulatory or contractual issue (personal data, payment data, health records, sovereign workloads). Not every sandbox needs approval.
- Turn on visibility first: confirm Access Transparency is enabled for the Google Cloud organisation, export its logs, and start CloudTrail queries on AWSServiceRoleForSupport. Visibility carries no support risk.
- Assign approvers: create the Azure dedicated approver assignments per subscription, the Microsoft 365 Customer Lockbox access approver role, and Google roles/accessapproval.approver on a group. Configure alternate email or Pub/Sub routing to a monitored queue.
- Pilot: enable Azure Customer Lockbox and Google Access Approval for one subscription or folder, raise a low-severity support case that needs data access, and walk through approve and deny. On Google Cloud, start with the "GA services only" enrolment option rather than the default that includes Preview services.
- Expand: enrol the remaining in-scope projects and subscriptions. Write a runbook entry so the support case owner tells the approver group when a request is coming.
- Add key control: for the most sensitive workloads, move to customer-managed keys, and on Google Cloud evaluate Key Access Justifications policies within Assured Workloads. Google advises against rejecting requests in production during the enablement window for external key managers, which can take up to 24 hours.
- Rollback: if approvals block an urgent incident, approve the specific request rather than disabling the feature. Disabling Microsoft 365 Customer Lockbox or Access Approval removes the control for every case; record any such change as an exception with an end date.
Small versus large organisations: a small team can run approvals from email with two named approvers and rely mainly on visibility. A large or regulated organisation should route requests into a ticketing workflow, map approvers per business unit, add key control for crown-jewel data, and report provider access metrics to the third-party risk committee. See the Third-Party Risk Management Guide.
Framework mapping
| Framework | Reference | How operator access controls satisfy it |
|---|---|---|
| NIST SP 800-53 Rev 5 | SA-9 External System Services; SA-9(5) Processing, Storage, and Service Location | Defines and monitors provider obligations; location fields in Access Transparency evidence where access happened |
| NIST SP 800-53 Rev 5 | PS-7 External Personnel Security; AC-6 Least Privilege | Approval workflow and time-limited grants for provider staff |
| NIST SP 800-53 Rev 5 | AU-6 Audit Record Review, Analysis, and Reporting | Review of Lockbox, Access Transparency and Support role logs |
| NIST CSF 2.0 | GV.SC-05, GV.SC-07, DE.CM-06 | Contract requirements, supplier risk monitoring, monitoring external service provider activity |
| ISO/IEC 27001:2022 Annex A | A.5.19, A.5.20, A.5.23 | Supplier relationships, security in supplier agreements, information security for use of cloud services |
| CIS Controls v8.1 | Control 15 Service Provider Management | Inventory and monitoring of service providers with access to data |
| Microsoft cloud security benchmark | PA-8 Determine access process for cloud provider support | Customer Lockbox applicability |
| MITRE ATT&CK | T1199 Trusted Relationship | The threat model: abuse of a trusted provider's access path |
Common misconfigurations
- No valid approver: approvers assigned at management group scope, or only PIM-eligible, so every request expires and support stalls. Fix: dedicated approver role per subscription, tested quarterly.
- Approval by habit: approvers click Approve without opening the linked service request ID. Require a matching ticket and record the reason.
- Logs enabled but unread: Access Transparency logs left in the project with default retention and no alert on THIRD_PARTY_DATA_REQUEST or unexpected locations.
- Bypass through IAM: a provider engineer or consultant given a standing IAM role "to help", which Google's own exclusions place outside Access Transparency. Remove or time-limit these grants.
- Overclaiming in audits: stating that "the provider cannot access our data" when the documented exclusions (break-glass, legal demand, exempt features) still apply. Describe the controls and their limits accurately.
- Forgetting the Support role: nobody reviews CloudTrail activity from AWSServiceRoleForSupport, or teams assume its permissions are static when AWS updates the managed policy roughly monthly.
Practitioner checklist
- List the workloads where provider staff access to data is a regulatory, contractual or sovereignty issue.
- Confirm Access Transparency is enabled for the Google Cloud organisation and its logs are exported to your SIEM.
- Enable Azure Customer Lockbox (support plan Developer or above) and Microsoft 365 Customer Lockbox where licensed.
- Assign at least two standing, dedicated approvers per in-scope subscription, tenant and Google Cloud scope.
- Route Lockbox email and Access Approval Pub/Sub notifications to a monitored queue, not a personal inbox.
- Alert on non-support justification codes, out-of-region accessor locations, auto-approved requests and configuration changes.
- Build a CloudTrail query for AWSServiceRoleForSupport activity and review it monthly.
- Remove or time-limit any IAM grants to provider personnel that bypass approval workflows.
- Use customer-managed keys, and Key Access Justifications where available, for data the approval controls do not fully protect.
- Document each control's exclusions in your risk register and third-party assessment.
Standards and references
- Microsoft Learn: Customer Lockbox for Microsoft Azure
- Microsoft Learn: Microsoft Purview Customer Lockbox
- Google Cloud: Understanding and using Access Transparency logs
- Google Cloud: Access Transparency exclusions
- Google Cloud: Overview of Access Approval
- Google Cloud: Key Access Justifications overview
- AWS: Using service-linked roles for AWS Support
- AWS: The Security Design of the AWS Nitro System, No AWS operator access
Related NHI Mgmt Group resources: Shared Responsibility Models Guide · Assured Workloads and Sovereign Controls Guide · EU Sovereign Cloud Options Compared Guide · Privileged Access Management Guide · Third-Party Risk Management Guide