$ azcmd security --verbose

Security is the architecture, not a feature

AzCmd operates inside other organizations' Azure tenants — a responsibility we designed for from the first line. This page describes how access is granted, constrained, exercised, and revoked. If your security team has questions it doesn't answer, we'd genuinely like to hear them: [email protected].

>_ identityMicrosoft Entra throughout

Every sign-in to AzCmd is a Microsoft Entra sign-in. There are no AzCmd-local passwords: your identities, your MFA, and your conditional access policies govern who can reach the console, exactly as they govern the rest of your Microsoft estate. Tenant onboarding uses the standard Entra admin-consent flow — the same mechanism your admins already use to evaluate and approve any enterprise application.

>_ connectCertificate-based tenant connectors

Once a tenant admin grants consent, AzCmd's connection to that tenant authenticates with certificates — not shared secrets, not stored passwords. Nothing a help-desk employee could copy out of a config file exists to be copied. Because the connection is agentless, there is also no software running inside your VMs to be compromised, patched, or audited.

>_ scopeLeast privilege by design

The permissions AzCmd requests are scoped to the VM operations it performs — starting, stopping, scheduling, and running the commands you configure. It does not ask for broad directory or subscription-owner rights. What a given AzCmd user can do is further narrowed by roles that match reality: engineers, help desk, and client contacts each see exactly the tenants and actions they need, and nothing more.

>_ isolatePer-tenant isolation and instant revocation

Each customer or business-unit tenant is a separate, independently revocable connection. Tenants never share credentials or connector identities. If you end an engagement — or simply change your mind — pull the Entra consent for that tenant and AzCmd's access ends immediately. There is nothing else to uninstall and no residual access to chase down.

>_ auditEverything on the record

Every action AzCmd takes — every schedule change, every start and stop, every command run, whether automated or manual — is logged with who, what, where, and when. When a customer, auditor, or incident review asks what happened, the answer is a search, not a reconstruction.

Security review? If you're evaluating AzCmd for an environment with formal review requirements, contact us at [email protected] — we're happy to walk your security team through the consent flow, the permission scopes, and the audit model in detail.

$ azcmd request-access

See the consent flow and audit trail on your own tenant.

Request early access