Power Platform in GCC High: Connector Availability and Workarounds

Power Platform runs in GCC High, but a smaller connector catalog changes your design. The catalog for US Government clouds marks each connector for GCC, GCC High, and DoD support, and many entries stop short of GCC High. That constraint drives how you build automations that handle CUI.

Power Platform in GCC High

Microsoft operates a distinct Power Apps US Government offering that includes GCC High. Microsoft provisions those environments in separate data centers and runs them on separate URLs. Your admins reach Power Apps at make.high.powerapps.us and Power Platform admin features at high.admin.powerplatform.microsoft.us. Power Automate uses high.flow.microsoft.us endpoints. Microsoft ties identity to your Microsoft 365 GCC High tenant and keeps content inside the US Government boundary described in the service documentation.

Microsoft targets different compliance baselines across sovereign clouds. The Microsoft Public Sector team describes distinct offerings and notes that GCC High and DoD target FedRAMP High and DoD SRG Impact Level requirements. That difference explains why service and feature availability diverges from commercial.

Connector availability reality

Microsoft maintains a live connector reference that flags availability per sovereign cloud. The table shows, for each connector, a column for GCC, GCC High, and DoD. You will find many connectors that appear in commercial and GCC but do not appear under GCC High or DoD. Teams should treat that catalog as the source of truth during design.

One example helps set expectations. Microsoft staff confirmed in a Q&A thread that the Microsoft To Do connector does not appear in the GCC High or DoD catalogs, even though it appears in commercial and some GCC tenants. Patterns like this repeat across consumer and third‑party services.

Plan connector usage with two habits:

Start with first‑party Microsoft connectors that the catalog marks as available in GCC High.
Validate availability for every connector in the live reference before you design a flow.

CUI and assessment scope implications

Power Platform can process CUI. That decision pulls the platform into your NIST SP 800‑171 and CMMC scope. NIST SP 800‑171 Revision 2 sets the requirements your team must implement. Assessors use the CMMC Level 2 Assessment Guide and the Cyber AB CAP to review those implementations inside your defined boundary.

You should treat connector choices as boundary decisions. Two controls frame the risk:

AC.L2-3.1.3 requires you to control the flow of CUI. A connector that leaves GCC High can route CUI outside approved channels.
SC.L2-3.13.1 calls for monitoring and protecting communications at external and key internal boundaries. A connector that calls a public API can create an external boundary that you must control.

Other controls land during design and operations:

AC.L2-3.1.1 drives access decisions for app makers and service principals.
AU.L2-3.3.1 drives logging for Power Platform actions and back‑end APIs.
SC.L2-3.13.8 drives encryption for data in transit between flows and APIs.
CM.L2-3.4.1 drives inventories and baselines for environments, solutions, and connectors.

Document Power Platform in your system security plan. Map the apps, flows, connectors, environments, and back‑end services. That record helps you show scoping discipline and control coverage. For SSP structure and mapping references, see System Security Plan for NIST 800‑171 and NIST 800‑171 to CMMC Level 2 Mapping.

Common gaps and safe workarounds

Teams hit two recurring gaps in GCC High:

Consumer services such as To Do and other personal productivity APIs often do not appear in GCC High.
Many third‑party SaaS connectors do not appear in GCC High or DoD.

You can address those gaps without pushing CUI outside the enclave:

Build on first‑party Microsoft services that the catalog lists for GCC High, then extend with custom connectors.
Stand up internal APIs that meet your enclave requirements, and call them from Power Apps or Power Automate using custom connectors.

The Power Automate US Government documentation states that Microsoft exposes connectors in GCC High only when the service meets the compliance and data handling bar for that cloud. Treat any service that does not appear in the GCC High column as out of scope for CUI. Do not route CUI through commercial or consumer connectors to close a feature gap. Design the integration inside your boundary instead.

Your DLP strategy should match that stance. Use Microsoft Purview to define rules that block flows and apps from sending CUI to external endpoints and non‑approved connectors. For patterns that support this, see Microsoft Purview for CUI DLP.

Custom connector and API design patterns

Custom connectors give you control over where data goes. A sound pattern looks like this:

Place a back‑end API inside your approved government cloud boundary and align it to your IL4 controls. Expose only the operations your app needs.
Publish a custom connector in your GCC High environment that calls that API over TLS with mutual or token‑based authentication.

That pattern keeps CUI inside your boundary and still enables low‑code apps and flows. It also gives you room to meet 800‑171 requirements:

You implement AC.L2-3.1.1 by granting access only to makers and service principals that need it.
You implement AU.L2-3.3.1 by logging connector calls and API operations in a central audit store.

Treat the connector as a system component. Inventory the OpenAPI definition, the authentication method, and the backing compute. Track versions and changes under CM.L2-3.4.1. Monitor traffic at the API tier to meet SC.L2-3.13.1 and enforce TLS to meet SC.L2-3.13.8.

Two additional tips improve outcomes:

Use environment‑level Data Loss Prevention policies to allow only approved custom connectors and first‑party connectors for production environments.
Separate maker environments for experimentation from production environments that handle CUI, and restrict connector creation in production.

Build‑time checks and operations

You can avoid redesign late in a project with a light checklist that the team runs at intake and release.

At intake:

Check the official connector reference and record GCC High support for each required connector.
Confirm the target URLs. Makers should use make.high.powerapps.us and high.flow.microsoft.us, not commercial endpoints.

During design:

Prefer first‑party Microsoft services that the catalog lists for GCC High, and replace missing connectors with custom connectors to internal APIs.
Define DLP policies that block external connectors in CUI environments and allow only the set you intend to use.

Before release:

Validate authentication flows end to end with Conditional Access policies in place. For background on policy design in GCC High, see Conditional Access for DFARS 7012.
Capture evidence for your SSP. Include connector configurations, API endpoints, and logging locations.

During operations:

Monitor the Microsoft connector catalog for changes. The table updates over time and may add or remove GCC High support for a service.
Review the Microsoft Public Sector blog and service descriptions for changes in sovereign cloud coverage, and assess impact to your apps and flows.

Practical references to keep close

Keep three Microsoft sources open while you work in GCC High:

The Power Apps and Power Automate connector reference that lists GCC High and DoD availability.
The Power Automate US Government service description that explains connector gating for compliance.
The Power Apps US Government overview that documents URLs, eligibility, data residency, and environment setup.

Microsoft also publishes a Product Placemat for CMMC 2.0 as a preview mapping. Use it as a design reference only. Microsoft labels it as informational and not an authorization or guarantee.