Organization gets certified. Consultants cash their checks. Documentation gets filed somewhere. Then compliance becomes a Word document ritual: screenshot the portal, sign the checklist, ship it. Three months later, an audit exposes configuration drift, hardcoded secrets, and vulnerable dependencies nobody noticed. The forensic evidence disagrees with the signatures. The fix isn’t stricter sign-offs or more checklists. It’s treating compliance as an engineering problem with automated CLI tools that run on every deployment.
Username and password for admin access? That’s not security, that’s security cosplay. You’re wearing the costume without any of the actual protection. One leaked credential and attackers walk right through your front door. Azure AD B2C with conditional MFA ends the costume party: risk-based authentication that only challenges when it matters. View a dashboard? Password’s fine. Delete production data? Prove you’re really you.
Three hours into a production incident, someone asks the obvious question. Silence. The terminal closed, the build log
expired last week, and your migration tool printed “Success” before forgetting everything. This scenario repeats
constantly: privileged CLI operations that modify production systems, then vanish without a trace. The fix requires
discipline, not genius: structured logging, user identity tracking, and persistent storage.
Most APIs expose personal data based on database entities, not caller needs. When a password reset endpoint returns a user’s full profile, purchase history, and marketing preferences, that’s purpose drift. This article shows how to restructure ASP.NET Core APIs around caller purposes using resource-based authorization, consent validation, and field-level access control.
Every Azure subscription I’ve worked with has the same problem: connection strings with embedded credentials in appsettings.json, Service Principal secrets checked into Git history, storage account keys hardcoded everywhere. The credential sprawl is real. These aren’t careless developers. These are smart people applying on-premises patterns where they don’t belong. Azure Managed Identity flips the model entirely. Instead of your application proving identity by presenting a secret, Azure proves identity on your application’s behalf through cryptographic attestation. No secrets in code. No credentials in configuration. No rotation ceremonies. The Azure SDK’s DefaultAzureCredential handles authentication automatically, working identically in local development and production. Combined with RBAC, you scope permissions to exactly what each application needs. Not Contributor-level access to the entire subscription. Just the specific operations on specific resources that the application actually requires. This article walks through credential anti-patterns I encounter constantly, then shows the correct implementation using Bicep and .NET’s DefaultAzureCredential. The migration path is pragmatic: within weeks, not months, you can have zero static credentials in your codebase.
