Alone a checklist is worthless.

Joshua Copeland and Jean-Paul Lizotte

Image generated by AI.

They look good in a board report. They check the compliance box. But they don't reflect how adversaries actually move, exploit, and pivot in cloud environments. What we're left with is "security theater"; the illusion of safety without the substance of resilience. It's all for show.

The Problem With "Best Practices"

"Best practices" sound comforting. They're the shiny guardrails vendors hand you, the box every auditor wants checked, the phrase every executive clings to when they don't really understand the risk. But here's the problem: most Azure best practices aren't actually designed to stop attackers, at least not today's attackers, they're designed to create the appearance of security. They standardize the minimum, not the maximum. They solve for compliance optics, not for adversarial pressure. And when organizations treat them as gospel, they end up building fragile systems that look secure on paper but crumble the moment someone decides to really test them.

They're marketing, not security.

Most Azure "best practices" are written to showcase how polished the platform looks, not how it actually holds up under attack. They're generalized, vendor-friendly configurations meant to look great in a PowerPoint deck or satisfy a compliance audit. The problem? Real adversaries don't care about clean dashboards or neatly aligned policies. They look for the exceptions, the legacy accounts no one touched, the misconfigured service principal quietly holding global admin. Best practices create the illusion of a fortress, but too often it's a cardboard cutout…perfect for a sales demo, useless in a breach.

They lag reality.

By the time guidance is published, attackers have already shifted tactics. MFA bypass kits, token theft, and misconfigured identity federations aren't addressed in the glossy PDFs. Standards be the vendor, industry, or government take months to years to formalize. When the threats are changing daily, they will never be accurate to the current threat landscape.

They measure compliance, not resilience.

Passing an Azure security benchmark is like acing an open-book exam. It doesn't prove you can perform under pressure; it proves you can read and can find the answers. That isn't bad, but anyone can click through a checklist, enable a few toggles, and generate a report that says "secure." But that doesn't mean your environment can withstand token theft, privilege escalation, or a lateral move through a misconfigured identity. Compliance shows you've followed the recipe. Resilience proves you can improvise when the fire alarm goes off and the recipe no longer applies. Attackers don't care if you scored 100% on a benchmark—they care about the gaps you left between the lines.

JP's Take: Building Real Resilience

Best practices are table stakes. What matters is how you harden the system against failure, drift, and compromise. That requires designing for attackers, not auditors:

• Automation with resilience in mind. Don't just automate toggles; automate recovery and self-healing. Infrastructure pipelines that detect drift and auto-correct reduce your attack surface faster than manual patching ever can.
• Peer review as a first-class security control. Automated deployments need human friction in the right places. Peer review on architecture changes and IaC pull requests catches the kinds of mistakes that lead to privilege escalation. It's less flashy than a dashboard, but far more effective.
• Field-level data protection. Encrypting disks and blobs is obvious. Encrypting sensitive fields inside databases and message flows is what frustrates attackers. Even if they pivot, what they pull is useless without keys.
• Resilient logging. If your logs live only in the same tenant you're defending, they're one rm -rf away from disappearing. Log-shipping to an isolated environment makes sure your forensics survives the breach.

This is how you move from theater to resilience engineering.

Beyond the Checklist: What Actually Works

Threat-driven baselines

• Log analysis.
• Log everything and have tools that analyse those logs for repeated "unusual" patterns including volume of accesses.
• Review the logs frequently.
• Use honeypots or deception assets to catch identity probing and credential stuffing early.
• Rotate service principal secrets and keys regularly, with automation enforcing rotation schedules.
• Build baseline "normal" behavior dashboards and alert on deviation rather than raw thresholds.
• Leverage AI to flag trends or hidden clues. But do not depend on it!

Identity abuse perimeter controls  

• Take the time to gate access. 
• Anonymous access should be denied at the border. 
• Apply conditional access policies that weigh device posture, network location, and behavioral analytics.
• Limit "just-in-time" access with automated expiration for elevated roles (Privileged Identity Management in Azure AD).
• Map out and prune "shadow identities" (service accounts, stale guest users) on a monthly cadence.

Automation with accountability

• All changes have an automated integration (CI). 
• The outcomes are reviewed by peers and signed off by them.
• Enforce "two-person integrity" for sensitive infrastructure changes: automation enacts the change, but a second peer signs off digitally.
• Tie every infrastructure change to a work item or ticket — the CI pipeline should fail if it can’t link the code change to intent.
• Keep immutable audit trails of automation actions in an external log store (e.g., append-only blob or SIEM connector).

Resilience testing Compliance reports: 

• Authentication & Identity Testing
• Authorization & Access Control
• Data Protection & Privacy
• Cloud Configuration & Infrastructure Testing
• Application Security (OWASP + Cloud Specific)
• Network & API Security
• Compliance & Supply Chain
• Code Scanning (Snyk, Sonarqube)
• Store the results in a separate cloud storage, highlight any changes in statuses. 
• Run tabletop exercises that simulate token theft, lateral movement, or log corruption — measure how long it takes to detect and respond.
• Integrate chaos security engineering: e.g., deliberately inject expired certificates, revoked tokens, or disabled MFA to test if detection and recovery trigger.
• Test data survivability: simulate loss of production logs and confirm your secondary log-shipping environment remains intact.
• Automate red team in a box: scheduled scans and scripted privilege escalation attempts run continuously, with results fed into backlog.
• Leverage AI to flag trends or hidden clues. But do not depend on it!

Security leaders love to brag about "following Azure best practices." Attackers love when you do too. Because they know those best practices weren't written for them. They were written to sell you peace of mind.

Our Close

• Automate with recovery in mind: pipelines that not only deploy, but self-heal and detect drift.
• Add human friction where it counts: peer review and two-person integrity for sensitive changes.
• Protect the data that matters most: field-level encryption, backup and survivable logging in isolated stores.
• Test for failure, not just compliance: rehearse breaches, inject chaos, and prove you can recover.

Real resilience starts when you stop worshipping checklists and start building systems that attackers hate and you will love.

With thanks to Joshua Copeland of Tulane University for his contributions to this article.