Azure: When Your Best Engineer Is a Risk
Security
24. Juli 2026 18:04

Azure: When Your Best Engineer Is a Risk

von HubSite 365 über Jonathan Edwards

No-Faffing Managed IT Support & Cyber Security Support. Made in Yorkshire, built for the UK.

MSP best engineer may be the biggest security risk; enforce Azure AD JIT, Conditional Access, Intune and Defender

Key insights

  • The video warns that your Best Engineer can become a single point of failure when one person holds broad, unchecked access and critical knowledge. This risk grows if that person leaves, gets phished, or makes an unchecked mistake.
  • MSPs should enforce a documented baseline (not tribal knowledge), enforce segregation of duties, remove standing admin rights with just-in-time elevation (PIM), and require phishing-resistant MFA for all privileged roles.
  • Harden identity and access by using managed identities, tightening key management (hardware security where possible), reducing the number of privileged roles, and removing unused apps and tenants to shrink the attack surface.
  • Embed security into development workflows with the principles Secure by Design, Secure by Default, and Secure Operations. Centralize governed pipelines, stop storing plaintext secrets, and protect build and deployment systems so secure behavior is automatic.
  • Monitor and respond: enable robust logging and alerting on privileged actions, run continuous monitoring, keep clear audit trails, and maintain fast remediation processes so incidents are detected and contained quickly.
  • Practical benefits and checklist for MSPs: reduce dependence on individual judgement, lower attack surface, and improve resilience. Quick checklist: a named baseline, PIM/JIT, conditional access, device policies via Intune, endpoint protection like Defender for Business, plus mandatory training and governance.

Overview of the Video

In a recent YouTube video, Jonathan Edwards argues that the person you trust most in IT can also be the single largest security risk to your business. He frames this as a common problem in managed service providers and internal IT teams, where one senior engineer accumulates broad, unchecked access and responsibility. Consequently, Edwards warns that departures, successful phishing attacks, or uncorrected mistakes by that engineer can expose the entire environment.


The Central Problem: Concentrated Trust

Edwards explains that many organizations inadvertently concentrate power and institutional knowledge in one account, creating what he calls the “Terry Problem” in a dramatic opening scenario. Furthermore, he says that this concentration often lacks segregation of duties, an audit trail, and ongoing oversight, so risk grows silently even while productivity appears high. As a result, teams may enjoy short-term speed but expose their tenants and pipelines to long-term systemic hazards.


Recommended Framework and Controls

To address these risks, Edwards lays out a standardized framework that prioritizes documented baselines and just-in-time access, rather than permanent standing privileges. He advocates for a documented, named baseline so systems no longer run on tribal memory, together with PIM and just-in-time elevation to remove permanent admin rights. Moreover, he stresses the need for phishing-resistant MFA on privileged roles and logging with active alerting on privileged actions so organizations detect misuse quickly.


How This Aligns with Broader Industry Thinking

Edwards’ message echoes recent industry efforts to embed security into engineering workflows, notably initiatives that promote security by design rather than simply adding tools. For example, he highlights identity hardening, stronger key management, and the removal of unused tenants as practical steps that lower the attack surface and improve resilience. Thus, his recommendations reflect a shift from reactive tooling to proactive governance and system design.


Tradeoffs and Implementation Challenges

Implementing the framework requires balancing speed and security, and Edwards acknowledges that tradeoffs exist when teams move from informal practices to enforced controls. For instance, just-in-time access and strict conditional access can slow routine troubleshooting and frustrate top performers who value rapid response, so change management is essential to gain buy-in. Additionally, setting up comprehensive logging and alerting increases operational overhead and can generate false positives, which teams must manage through tuning and staff training.


Operational Practicalities for MSPs

Edwards recommends specific operational steps that MSPs can take, including documenting standard tenant configurations and applying conditional access baselines consistently across clients. He also highlights device management via Intune and Defender for Business enrollment as ways to control endpoints and reduce lateral movement after compromise. Therefore, MSPs must plan for the initial investment in automation and policy enforcement while expecting to reap reduced incident response time and lower breach impact later.


Cultural and Human Factors

Beyond technology, Edwards emphasizes that culture matters: security succeeds only when people and processes align with tooling. He cautions that training and governance are necessary because capable engineers may bypass controls under pressure, paste secrets into public tools, or use unmanaged workflows unless prevented by system design. Consequently, organizations must combine mandatory training with enforced guardrails to change habits and protect sensitive assets.


Measuring Success and Remaining Risks

Edwards outlines measurable outcomes such as fewer standing admin accounts, more logged privileged actions, and reduced unused tenant count as indicators of progress. However, he also warns that no single approach eliminates risk; adversaries and human error evolve, so continuous monitoring and periodic policy reviews remain essential. Thus, success requires persistent attention to metrics, rapid remediation playbooks, and a culture of accountability.


Why This Matters Now

The video is timely because modern development practices and AI-assisted workflows increase the speed at which engineers can access code, data, and systems, magnifying the potential impact of a single compromised account. Therefore, Edwards urges MSPs and internal teams to treat privileged access as a systems problem and not a matter of trust alone. In short, by standardizing baselines, limiting permanent privilege, and hardening identity, organizations can keep the benefits of top engineers while reducing systemic risk.


Final Takeaway

Jonathan Edwards’ video is a practical call to action for teams to stop building fragile reliance on one person’s knowledge and access. By combining documented baselines, just-in-time privilege, phishing-resistant MFA, and active logging, organizations can balance operational speed with stronger security posture. Ultimately, adopting these steps demands effort and discipline, but Edwards argues that the long-term security and business resilience make the tradeoffs worthwhile.


Security - Azure: When Your Best Engineer Is a Risk

Keywords

best engineer security risk, insider threat engineers, privileged engineer cybersecurity, top engineer data breach, devops insider risk, employee sabotage prevention, managing trusted employee risk, privileged access management engineers