Power Automate Security Review
Every Power Automate flow runs on someone’s connection, so it can reach further than the person who triggers it. We review flow ownership, connections, HTTP triggers and run history. CREST-certified testers, fixed price from £3,920 for a 3-day single-environment scope, quoted within 24 hours.
- Unlimited retesting
- Unlimited pre-retesting
- No hidden fees
“I would highly recommend EJN Labs to any organisation seeking reliable, detailed, and well-managed penetration testing services, particularly for government or enterprise-level projects.”
“There wasn’t another company we could find that could deliver what we needed in the timeframe we needed. The client loved it, and we got instant ROI from the engagement.”
A flow has no identity of its own: every trigger and action runs through a connection, and that connection’s identity, not the flow’s, decides what it can actually reach.
A Power Automate flow runs on someone else’s identity, never its own
A Power Automate flow has no identity of its own. Every trigger and action authenticates through a connection, and a connection belongs to whoever created and authorised it, not to the flow itself or the person who happens to be running it. Connections are shared between Power Automate and Power Apps, so a connection built for one shows up in the other, and whatever that connection is authorised to do travels with it into every flow or app that uses it.
Who can change a flow and who can only run it are two different permission levels, and the gap between them is wide: a co-owner has essentially the same control as the person who built the flow, while a run-only user only gets to trigger it. That gap narrows again at the connection level, because sharing a flow with run-only users can be set to run under the owner’s connection or under the Run-only user provides connection option, which switches execution to the runner’s own credentials for that step. We review this the same way we do for the Power Apps environment a flow’s connections are often shared with, since the same connection can sit behind both.
Flows that start from the When an HTTP request is received trigger add a further identity question: the callback URL carries a shared access signature that, on its own, is the only thing standing between an outside caller and the flow, unless the trigger is configured to require a Microsoft Entra ID token instead. We test that trigger, the data policy governing which connectors a flow is allowed to combine, and the environment boundary a flow’s connections and Dataverse access are confined to, alongside any desktop flow and the machine credential behind it.
SCOPE
What we review in your Power Automate flows
Flow ownership, co-owners and run-only sharing
A cloud flow’s original creator can never be removed, but any co-owner added afterwards has essentially the same control: viewing run history, editing the flow’s design, managing its connections, and adding or removing other co-owners. Run-only users get none of that, only the ability to trigger the flow the way the owner intended, and that access can be assigned to a security group instead of listed user by user. We test who actually holds co-owner rights against who was meant to, and whether a group used for run-only access still matches the environment’s own access policy.
Connection identity and the connections shared with Power Apps
Every trigger and action in a flow runs through a connection, and a connection belongs to whoever created and authorised it, not to the flow itself. Connections are shared between Power Automate and Power Apps, so a connection created in one service is available in the other, which means a change to who holds that connection, or to what it’s authorised for, affects every flow and app built on it. We map every connection a flow depends on and test what happens if the person who authorised it leaves, changes role or has their access revoked.
Run-only sharing: whose credentials the flow executes under
When a flow is shared with run-only users, each connection it uses can either stay authorised as the owner’s or be switched to the Run-only user provides connection option, which makes the flow execute in the context of the run-only user’s own credentials instead. Where the flow touches a Dataverse table, that runner then needs whatever Dataverse role, such as Basic User, actually grants the rights the flow’s actions perform. We test which option is set on every connection in scope, and whether the runner’s own privileges match what the flow does on their behalf.
The HTTP request trigger’s callback URL and SAS signature
The When an HTTP request is received trigger generates a callback URL containing a shared access signature in its sig parameter, and by default that signature, rather than a login, is what authorises a caller to run the flow. Regenerating the SAS key issues a new signature and invalidates the old one immediately, which is the only way to revoke a URL that’s been shared too widely or leaked. We test how the URL has been distributed, whether it appears in code, logs or a third-party system, and whether the key has ever been rotated.
Who can call the trigger: OAuth authentication and tenant restriction
An HTTP-triggered flow can be configured to require a Microsoft Entra ID token instead of relying on the URL alone, restricting the trigger to any authenticated user in the tenant or to specific users or principals, which the flow checks by matching the audience, tenant and object ID claims in the bearer token. Where this isn’t configured, anyone who obtains the URL and its current signature can invoke the flow with no further check. We test which authentication option is actually applied against what the flow’s action is authorised to do once called.
Privilege mismatch between a flow’s trigger and its actions
Each action in a flow authenticates through its own connection, so nothing forces every step to run at the same privilege: a flow might trigger on an event that only needs the Basic User role, then carry an action further down that runs against Dataverse under a connection authorised at System Customizer or higher. We test the privilege each action’s connection actually carries against what the flow needs it to do, not just what the trigger implies.
Sensitive data left visible in run history
Run history shows the inputs and outputs of every trigger and action unless the Secure inputs and Secure outputs settings are turned on for that specific step, in which case the values are replaced with empty braces instead of being shown. The setting has to be applied action by action, so a flow can have secure outputs on one step and a password or token sitting in plain view on the next. We check every action that handles a credential, token or personal data for whether secure inputs and outputs are actually switched on, not assumed.
Data loss prevention policy and connector classification
A data policy, still widely known as a DLP policy, sorts every connector into a Business, Non-Business or Blocked group, and can be applied at tenant level, where specific environments can be included or excluded, or directly against a single environment. A flow that combines connectors from different groups in the same run is blocked once a policy covers it, but only for the environments and connectors that policy actually names. We test what the current policy blocks and classifies against what the environment’s flows are still calling, including any connector added since the policy was last reviewed.
Environment separation and the default environment
A flow, like the connections and gateways it depends on, is bound to the environment it was built in and can only reach a Dataverse database deployed in that same environment. Every tenant also has one default environment created automatically, and every new user is added to its Maker role with no admin action required, while no one is added to its Environment Admin role by default. We test what has been built in the default environment, and whether a flow or connection anywhere still points at the wrong environment after a move between them.
Desktop flows and machine credentials
A desktop flow connection creates a Windows session on the registered machine to run it, and Microsoft’s own guidance is to trust the co-owners of a flow before letting them use that connection, since a co-owner can trigger the desktop flow like any other action. Unattended runs need dedicated capacity on the machine, and where several machines share one flow, a machine-credential mapping backed by Azure Key Vault or CyberArk decides which credential signs in on which machine. Where desktop flows are in scope, we test who can trigger them, what credential each mapping actually applies, and what the session it opens can reach.
OUR PROCESS
Microsoft Power Automate Security Review: From Scope to Attestation
Flow, Connection and Environment Mapping
We list every flow in scope, who owns and co-owns it, which connections and environments it runs in, and how it’s triggered.
Ownership, Sharing and Connection Testing
We test flow and connection access under every ownership and run-only tier in scope, including which identity each connection actually executes as.
Trigger, DLP and Environment Testing
We test HTTP and other triggers directly, review the data policy against the connectors flows are still calling, and check environment separation and any desktop flow machine credential.
Reporting and Retest
Executive summary, technical report with CVSS scores and reproduction steps, a walkthrough call, free retest after remediation and an attestation letter.
CREDENTIALS
Verified Accreditations Auditors Accept
Every credential below is independently verifiable. UK procurement teams, FCA supervisors, ISO 27001 / SOC 2 auditors, and cyber insurance underwriters all recognise these standards.
GET YOUR QUOTE
Get a CREST Power Automate pen test quote in 24 hours
A fixed-price quote back in one business day, from a named CREST assessor. No sales pipeline, no chasing.
- CREST and IASME accredited. Testing your auditors and clients already recognise.
- Fast-track testing within 24 hours where required. Free retest of every fix included.
- Live findings via your client portal, not a four-week PDF.
- Fixed price from £3,500 for a single-role, single-app scope, agreed up front. Most engagements run £5,000 and up. No day-rate surprises.
Dan WilcocksonFounder, CelloriUnder NDA Further named references available on a scoping call.
- We reply within one business day with a fixed-price quote from a named CREST assessor.
- You approve the scope and we book a start date, usually within 24 hours.
- Live findings land in your client portal as we test, with a free retest of every fix.
Get your fixed pen test quote in 24 hours
Quote request received
We will reply within one business day with your fixed-price quote from a named CREST assessor.
Your data stays with us. No newsletter signup.
or book a 20-min scoping call first
We reply within one business day. Your data stays with us. No newsletter signup.
COMPLIANCE READY
Reports Mapped to Every Framework
Findings are written so your team can reference the report against each framework without translation work.
ISO 27001:2022
Annex A.8.8 management of technical vulnerabilities plus A.5.15-5.18 and A.8.2-8.5 access control validation.
SOC 2 Type I & II
CC6 logical access, CC7 system operations, CC8 change management evidence.
PCI DSS
Requirement 11.4 application penetration testing across cardholder data environments, including ecommerce penetration testing for online retail platforms.
FCA SYSC
SYSC 4.1.1R, 6.1.1R, 13 mapped to each finding for FCA-regulated firms.
UK GDPR
Article 32 effectiveness testing, customer-data security controls, ICO-acceptable evidence.
Cyber Essentials Plus
Direct certification through our IASME body status, single-vendor delivery.
PRICING
Transparent Microsoft Power Automate Security Review Pricing
Pricing depends on the number of roles, integrations and environments in scope. See our pricing page for how we quote.
3 to 4 testing days
Single user role, basic CRUD application, marketing website with auth. Around 5 working days from kickoff to report.
Get a fixed quote4 to 6 testing days
Multi-role SaaS, business application with payment integration. Around 8 to 12 working days from kickoff to report.
Get a fixed quote6 to 8 testing days
Multi-tenant platform, complex authorisation matrix, integration-heavy applications. Around 15 to 20 working days from kickoff to report.
Get a fixed quoteSECTORS
Sectors We Test Power Automate For
Sector-specific scoping for regulated UK organisations.
Fintech & FCA-Regulated
FCA SYSC, Open Banking FAPI 1.0, PSD2 SCA, payment-flow scrutiny, KYC/AML testing.
Fintech sector pageSaaS Companies
SOC 2 Type I & II evidence, multi-tenant boundaries, role escalation, customer-tenant isolation.
SaaS sector pageLaw Firms
SRA Cyber Standard, privileged data, conveyancing fraud defence, partner-tier procurement.
Law firm sector pageHealthcare
NHS DTAC, DSP Toolkit v6, UK GDPR Article 32, EHR systems, telehealth platforms.
Healthcare sector pageInsurance
FCA / PRA Operational Resilience, cyber underwriting, claims data, broker portals.
Insurance sector pagePublic Sector
CCS / G-Cloud framework, NCSC-aligned, citizen-facing services, PSN-compliance scrutiny.
Public sector pageWHY EJN LABS
What You Get From Microsoft Power Automate Security Review
Six concrete differentiators competitors don’t all match.
CREST-Certified Testers, Verifiable
Every test by a CREST-certified pen tester (CRT, CCT APP, CCT INF where applicable). Verify our company status at crest-approved.org.
24-Hour Startup, Where Required
From signed scope to active testing in a single business day for incident response, audit deadlines, or regulator-driven timelines.
Live Findings, Not 4-Week PDFs
Critical issues reported during testing through your client portal. Your team remediates while testing continues.
Audit-Ready Reports
Executive summary plus full technical report with CVSS scores and explicit framework mappings (ISO 27001, SOC 2, PCI DSS, FCA SYSC).
Free Retests, Standard
Verify remediation of every finding before close-out. Letter of attestation for audit submission included. Most competitors charge £1,500-£3,000 per retest.
UK-Based CREST Testers
Every engagement performed by vetted, UK-based CREST-certified testers, matched to your needs, security clearance, and compliance scope.
FAQ
Frequently Asked
What access do you need?
Co-owner or maker access to the flows in scope, plus at least one login for each ownership tier, run-only assignment and connection identity you want tested. Read access to the environment’s data policy, security roles and connection list isn’t required to start, but it speeds up confirming what we find.
Will you touch our live data?
We test read-only against production by default. Where proving a write, update or delete action needs real records, we agree a sandbox environment or specific test data with you first, and anything we create during testing is documented and removed afterwards.
Is this hosted on our infrastructure or Microsoft’s?
Power Automate and the connections, environments and Dataverse behind it run entirely on Microsoft’s infrastructure, so there’s nothing for you to host. The test is scoped to your flows, connections, triggers, data policy and environment configuration, not to Microsoft’s platform itself.
Does this cover Power Apps or SharePoint too?
No. Where a flow’s connections are shared with a Power App built on the same Dataverse environment, the app-level sharing, security roles and custom components are covered on our Power Apps page. Where a flow is triggered from a SharePoint list or library, the site’s web permissions and table-level access sit on our SharePoint page; this page is scoped to the flow itself, not either of those surfaces.
What is out of scope?
Other tenants’ flows and environments, Microsoft’s own infrastructure, denial-of-service testing, and the Power Apps or SharePoint surfaces a flow connects to, which we cover on their own pages, are all out of scope here.
Is penetration testing our own Power Automate environment allowed under Microsoft’s rules?
Yes. Microsoft’s penetration testing rules of engagement for its cloud services permit testing your own tenant and the assets you’re authorised for, provided you don’t access data or systems you don’t own, don’t use credentials that aren’t yours, and don’t disrupt the service for other tenants, and we test inside those rules.
How long does a Power Automate test take?
A single-environment engagement covering a handful of flows and connections typically runs to a 3-day scope. More flows, connectors, run-only tiers or a desktop flow estate extend it, and we confirm the exact day count once we’ve seen the environment.
Do you need the source of any custom connector or desktop flow script?
No, though if the environment uses a custom connector or a desktop flow built on script-based actions, having the definition or script available speeds up root-causing anything we find. A source code review is a separate service that pairs well with this one.
20+ CREST-accredited testing services in one place
Web, mobile, API, cloud, AI, infrastructure, red team. Pick the test that fits your environment.
Get a fixed price for your Power Automate environment
Every Power Automate flow runs on someone’s connection, so it can reach further than the person who triggers it. We review flow ownership, connections, HTTP triggers and run history. CREST-certified testers, fixed price from £3,920 for a 3-day single-environment scope, quoted within 24 hours.
