We review your Azure tenant the way we secure our own.
We run production workloads on Azure in Australian regions, and we know from operating them where tenants actually break.
An Azure security review is a structured examination of your tenant across the six areas where cloud compromise starts and goes unseen: identity, network, secrets, logging, misconfiguration, and over-privilege. Black Shard runs the review by hand, validates every finding, and hands you a remediation plan tied to Azure-native controls. You do not get a re-badged scanner export.
We hold ourselves to the standard we recommend. Aurii, our clinical-software venture, runs on Azure in the Australia East region: Container Apps for the app server, PostgreSQL with row-level security isolating tenant health data, Key Vault for secrets, and GitHub Actions deploying through workload identity federation so no long-lived credential sits in the pipeline. We secure that stack every day, under Australian privacy obligations.
What the review covers
The review examines your tenant, not a template. Every area below is assessed against what your environment actually runs, who touches it, and what an attacker positioned inside it could reach.
- Identity: privileged role assignments in Entra ID, conditional access coverage, multi-factor authentication on administrative accounts, guest and dormant accounts, legacy authentication, and every service principal holding a credential.
- Network: what is internet-facing and why, public network access on storage and database endpoints, network security group rules, and where private endpoints should replace public exposure.
- Secrets: where credentials actually live, Key Vault usage and access policies, secrets sitting in app settings, pipeline variables or code, rotation discipline, and whether deployments authenticate through workload identity federation or long-lived client secrets.
- Logging: diagnostic settings across subscriptions, activity and sign-in log retention, and whether the telemetry exists to detect an attack while it is happening and reconstruct it afterwards.
- Misconfiguration: resource-level configuration on storage accounts, databases, container platforms and TLS posture, checked against the platform's own hardening guidance.
- Over-privilege: Owner and Contributor sprawl at subscription scope, service principals holding more than their job requires, and access that outlived the project that justified it.
We run Azure ourselves. It shows in the review.
A reviewer who has only ever audited Azure reads configuration against a checklist. A reviewer who operates Azure knows which defaults are dangerous, which findings are theoretical, and which quiet misconfiguration is the actual foothold. That judgement comes from running production workloads, watching deploys, rotating credentials, and being the one accountable when something is exposed. We do all of that daily.
It also changes the remediation. Because Black Shard is a software engineering firm as well as a cybersecurity firm, the fixes we write are the fixes an engineer can ship: named Azure controls, in the order your team should apply them, with the operational consequences stated. Advice that ignores how the workload actually runs gets deferred; advice written by people who run workloads gets done.
Our own posture is public on our trust page: SMB1001:2026 Gold, held by the legal entity and verifiable on CyberCert's public registry, alongside self-assessment against the ASD Essential Eight, labelled exactly that. We ask you to trust our review, so we make our own position checkable first.
What you get at the end
Two documents. The findings report tells you where the tenant stands. The remediation plan tells you what to change, in what order, using controls you already pay for. Both are written in plain English, for the team that will do the work.
- A findings report ranked by real impact, every finding validated by hand, written in plain English with the evidence to reproduce it.
- A remediation plan tied to Azure-native controls: Entra ID conditional access, Azure Policy, Key Vault, private endpoints, diagnostic settings, and Defender for Cloud where it earns its place.
- A prioritised fix order, so remediation starts with the changes that remove the most risk.
- Plain-English remediation guidance for every finding, written so your own team can execute it.
What goes wrong in most Azure tenants?
The same patterns recur, and almost none of them need an advanced attacker. They need someone to look. Privilege accretes: an Owner assignment handed out during a migration is still there years later, attached to an account nobody has reviewed since. Service principals carry client secrets that never expire, created before workload identity federation existed and never revisited. Secrets drift out of Key Vault into app settings, pipeline variables and the occasional repository.
On the network side, storage accounts keep public network access because an integration needed it once. Legacy authentication stays enabled for one workload nobody can name. And the most common failure is the quietest: diagnostic settings were never configured, so when something does happen, the activity log has already aged out and there is nothing to investigate. Underneath all of it sits ambiguous ownership, a tenant stood up by a partner who has since moved on, with nobody inside the organisation holding the whole picture.
A review exists to replace that ambiguity with a ranked, evidenced list of what is true in your tenant today.
How the review runs
The three-step method on our approach page applies here as it does to every engagement. We read the real risk first: your tenancy layout, the workloads that matter, the obligations you carry. Then we examine the tenant the way an adversary would read it, looking for the path rather than the checkbox. Then we report like engineers, with a concrete fix for every finding.
Access is least-privilege throughout, the same practice we publish on our trust page: people and systems get only the access the work requires, and no more, which for a review means read-level roles scoped to the engagement. The timeframe is agreed before we start, and because the tenant is the workplace, the review is delivered remotely as naturally to Perth or Hobart as to Brisbane.
It runs as a one-off assessment, or as the opening move of an ongoing advisory arrangement if you want a standing security seat afterwards.
How much does an Azure security review cost?
We do not publish prices. Any single number would be wrong for most tenants, either padded for the small ones or misleading for the large ones. The effort is driven by the number of subscriptions and environments, how much workload runs in the tenant, and the size of the identity estate: users, service principals, and privileged roles.
What is fixed is the scope. The engagement runs with a defined target, timeframe, and deliverable agreed before any work starts, as a one-off assessment or the opening of an ongoing retainer. Tell us the shape of your environment and we will scope it.
Every engagement includes
A director on the work
A director reads the brief, scopes the engagement, and stays accountable for the result.
Fixed scope, quoted first
Scope, timeframe, and price are agreed before work starts.
Findings validated by hand
Every finding is checked by a human, written in plain English, and paired with a concrete fix. Raw scanner output is never forwarded.
A fix order your team can ship
Remediation sequenced by removed risk, tied to Azure-native controls.
Least-privilege access
We take only the access the work requires, and client data sits in Australian regions.
A report that is yours
Written for your engineers and your board, and kept confidential.
Questions, answered
- What access do you need to our tenant?
- Reader-level roles scoped to the review: typically Global Reader in Entra ID and Reader at the relevant subscription scopes, agreed at scoping and removed when the engagement ends. We do not ask for write access to run a review.
- How long does an Azure security review take?
- The review runs as a fixed-scope engagement, so the target, timeframe, and deliverable are agreed before we start. Subscriptions, environments and workload count drive the effort: a single-subscription tenant reviews faster than a multi-subscription estate. Either way, the timeframe is set before any work begins.
- Is this an audit or a certification?
- No. It is an engineering review of your tenant, not a certificate. We hold SMB1001:2026 Gold ourselves, verifiable on the CyberCert public registry, and we work against the ASD Essential Eight as a methodology. If certification is your goal, the review's findings feed directly into compliance readiness work.
- We already have Defender for Cloud and a secure score. Do we still need a review?
- Secure score is a useful signal and we read it. What it cannot judge is intent: whether a permission is proportionate to its purpose, whether an exposure is deliberate, or whether anyone would act on the alert. A review exists to add that judgement.
- Do you review Entra ID as part of this?
- Yes. Entra ID is the identity control plane of your tenant, so identity review covers it by default: privileged roles, conditional access, service principals and their credentials. If you want the wider Microsoft 365 estate examined, raise it in the brief and we will tell you honestly whether it belongs in this review or in a separate piece of work.
- Can you fix what you find?
- Yes. We are a software engineering firm as well as a cybersecurity firm, so remediation can run as advisory support or hands-on engineering after the review. The plan is also written so your own team can execute it without us.
Related reading
The full practice: Security advisory & vCISO.
Know what is true in your tenant today.
Australia-wide, from our Brisbane head office. Someone will contact you as soon as possible.