Power Platform Community Forum Thread Details

Recently, I was working in a GCC High environment and we discovered (reported to Microsoft) that my account was being used to save over work, make changes to formulas and workflows in Power Apps Canvas and Power Automate. It was tedious to report it and caused a lot of issues with me being able to successfully deploy. One of the discoveries is the bad actor was using Visual Studio Code/Angular to alter a formula to hide and show on visible. The bad actor used Visual Studio Code and Angular to change the value of true to equal false and false to equal true. In the environment we are not allowed to use Visual Studio Code since NPM and other tools are blocked from being downloaded. As Power Platform is being made available to GCC High environments.

1) What tools can be used to discover when Visual Studio Code is being used to alter the app code,
2) How can we identify if the changes are not being made by the owner/co-owner in the Canvas App or Power Automate
3) Is there anyway for 2 factor authentication
4) Is there a way to ensure that the account is being used from the same computer and more importantly how can we ensure that if the developer account is hacked the bad actor can be identified and stopped? I have been a developer for over 17 years and love the product but as hacking gets more sophisticated I do not think we can rely on the current methods for making changes safely and securely.

G Brown

Categories:

GCC, GCCH, DoD - Federal App Makers (FAM)

Hi,
What you went through is serious, and the right place to harden this is identity and change control, not trying to police which editor someone used. The good news is the platform covers most of what you're asking, and the core pieces work in GCC High. Quick answers to your four questions:

You can't detect "VS Code" itself, and that's the key thing. Power Platform doesn't see what local tool was used, but it does log the result. Turn on Power Platform auditing and Microsoft Purview will show every app patch/publish, flow edit, and solution import, including which account did it and when. That's how you spot unexpected changes.
Pair two logs. Purview tells you which account made the change. The Entra ID sign-in logs tell you whether that account's session came from a normal device and location or something suspicious. A change that lines up with an odd sign-in is your red flag. Defender for Cloud Apps can flag the anomalies automatically.
Yes, MFA is fully supported. Use Entra Conditional Access to require it for Power Apps, Power Automate, and Dataverse. For a developer account, use phishing-resistant MFA (a FIDO2 key), not SMS, since that resists the token-theft attack you likely hit.
There's no literal "same computer only" lock, but you get close by requiring a compliant/Intune-managed device in Conditional Access (blocks unmanaged machines) and turning on the IP firewall with cookie binding (restricts access to your network ranges and blocks stolen-token replay). If an account is compromised, Entra flags the risky sign-in, Purview shows what changed, and you stop it by revoking sessions, resetting the password, and disabling the account, with near-real-time effect via Continuous Access Evaluation.

If I were you, I'd start with three things: phishing-resistant MFA plus compliant-device Conditional Access on every maker account, Power Platform auditing turned on, and the IP firewall with cookie binding on production. That closes the exact gap you described. Then add Sentinel or Defender for ongoing alerts.
And since you reported it already, have your admins pull the Purview and Entra sign-in logs for the incident window so the account, IPs, and devices are documented.
Hope that helps, and sorry you had to deal with it.