An unblockable connector is a built-in integration in Microsoft Power Platform that cannot be fully disabled through DLP policy controls. It can still be used to move data between services, which limits the administrator’s ability to enforce allow and block decisions at the connector level.
What Makes an Unblockable Connector Different
An unblockable connector is not just another integration option, it is a connector that sits outside the administrator’s normal allow-and-block enforcement model. In Microsoft Power Platform, that means policy can still shape some usage patterns, but it cannot fully remove the connector as a data-moving path.
The practical difference is control scope. Most connector governance assumes the platform can enforce a clear decision at the connector boundary, but an unblockable connector weakens that boundary by design. That makes the connector a permanent part of the data path, even when security teams would prefer to prevent it.
This matters because the security conversation shifts from “can we block it?” to “how do we govern what it can move, who can use it, and under what conditions?” The term is therefore about platform control limitations as much as it is about integration capability.
Why It Matters for Data Governance
Unblockable connectors are important wherever administrators rely on NIST Cybersecurity Framework 2.0 style governance to separate approved from unapproved data flows. If a connector cannot be fully blocked, then policy design must account for residual transfer paths rather than assuming perfect containment.
That changes how teams think about data classification, tenant boundaries, and acceptable use. A connector that remains available despite DLP rules can become a sanctioned exception path, which makes ownership and review more important than simple on or off control.
The most useful comparison is not with a typical low-risk integration, but with any control surface where policy intent and enforcement capability do not fully align. In practice, the gap between policy and actual connector behaviour becomes the real governance issue.
Security Implications and Control Limits
Because unblockable connectors can still move data between services, they can create bypass conditions for data loss prevention programs that depend on connector-level blocking. This is especially relevant when sensitive records, internal content, or regulated information may be copied into another service through a path that policy cannot eliminate.
That does not mean the connector is inherently malicious. It means defenders must treat it as a constrained control point and look for compensating controls such as service scoping, environment separation, monitoring, and tighter approval of the business process that depends on the connector.
For identity and access governance, the key issue is whether the connector’s use is tied to least-privilege access decisions and reviewed data movement permissions. If the platform cannot fully block the connector, then authorization, oversight, and logging carry more of the burden.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Unblockable connectors create residual data-flow risk that governance must account for. |
| PR.AC-4 — Access Permissions and Authorizations | Connector use still depends on who can invoke it and what data it can move. | |
| Recommendation — Define acceptable residual connector risk and review exception paths in your risk register. Restrict connector usage to approved roles and tightly scoped authorizations. | ||
| CIS Controls v8 | 6.3 — Manage and Control Administrative Privileges | Administrative control of connector capabilities depends on limiting privileged misuse paths. |
| 3.3 — Configure Data Access Control Lists | Connector behavior is governed by access decisions that shape who can move data. | |
| Recommendation — Limit privileged accounts that can alter connector settings or create risky data paths. Apply access controls that reduce who can initiate or expand data transfers. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | The term centers on where enforcement cannot fully block a connector-based data path. |
| SC-7 — Boundary Protection | Unblockable connectors weaken boundary-style assumptions about controlled data exchange. | |
| Recommendation — Enforce the narrowest feasible access rules around connector-enabled data movement. Treat connector paths as controlled boundaries and monitor all cross-service transfers. | ||
Practitioner Guidance
Governance implication: Treat unblockable connectors as exception paths that require explicit business justification and documented ownership. The control decision is not simply whether the connector exists, but whether its permitted data flows are narrow enough to remain acceptable.
What to watch for: Pay attention to connectors that can transmit sensitive content across apps or tenants even when DLP policy says they should be restricted. If the connector remains usable despite policy intent, the likely failure is a gap between policy design and actual enforcement.
Practitioner takeaway: Review these connectors as part of data-flow governance, not as a simple connector catalog entry, because the residual risk lives in what they can still move.
Related resources from NHI Mgmt Group
- Should organisations use connector-less deployment for on-prem DSPM where possible?
- What do security teams get wrong about connector credentials in infrastructure automation?
- Why do third-party connector patterns create NHI risk even when tokens are refreshed automatically?
- How can organisations tell if connector coverage is actually sufficient?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
