Assess Azure VMs, App Service, Functions, AKS, containers, registries, images, patching, endpoint protection, vulnerability findings, and closure evidence.
Secure build, deploy, run, and retire
Azure workload security spans virtual machines, virtual machine scale sets, App Service, Functions, Kubernetes, containers, registries, images, automation, extensions, runtime identities, and software dependencies. Each service divides responsibility differently. The organization must know which operating systems and runtimes it patches, which platform settings Microsoft maintains, how code and images enter production, which identities workloads use, how vulnerabilities are found, and how fixes are verified.
This guide focuses on vulnerability and hardening evidence across IaaS and PaaS. It complements the cloud workload, container, and image vulnerability scanning service by explaining the full assessment and remediation context around the scan results.
Workload inventory
The customer usually owns guest operating-system hardening, patching, endpoint protection, local accounts, software, extensions, secrets, host firewall, vulnerability remediation, application configuration, and backup. Azure manages the physical host and fabric.
Microsoft manages more of the operating platform, but the customer still owns application code, dependencies, authentication, managed identities, access restrictions, TLS, configuration, deployment slots, secrets, logging, and supported runtime selection.
Responsibilities include cluster identity, API access, node pools, version support, network policy, workload identity, admission control, image provenance, registry access, secrets, runtime security, vulnerabilities, and Kubernetes RBAC. The exact split depends on the service and configuration.
Automation can hold broad permission and execute at scale. Review identities, hybrid workers, scripts, variables, certificates, webhooks, repositories, approvals, logging, and the ability to change production.
Workload security lifecycle
Virtual machines
A VM assessment should combine Azure configuration, guest evidence, vulnerability data, endpoint protection, identity, network reachability, monitoring, and recovery.
| Area | What to check | Evidence | Business risk |
|---|---|---|---|
| Image and support | Publisher, image, generation, OS version, lifecycle, custom image owner | VM and image inventory, support records | Unsupported operating systems accumulate unfixable exposure |
| Patch management | Azure Update Manager, orchestration mode, assessment, maintenance configuration, reboot behavior, exceptions | Compliance export, job history, change tickets | Known vulnerabilities remain exploitable or updates cause unplanned outage |
| Endpoint protection | Defender for Endpoint or approved EDR, sensor health, tamper protection, exclusions, alert routing | Coverage report, device timeline, sample incident | Compromise may persist without detection or containment |
| Vulnerability assessment | Defender for Servers, agentless scanning, authenticated scanner, software inventory, finding age | Asset findings, scan scope, timestamps, exceptions | Critical exposure is unknown or mis-prioritized |
| Administrative access | Bastion, JIT, Entra login, SSH keys, local accounts, RDP, serial console, extensions | NSGs, JIT policy, login roles, account inventory, logs | Stolen credentials or public management ports enable takeover |
| Disk and data | Encryption, customer-managed key need, temporary disk, snapshots, backup, secret storage | Disk settings, Key Vault, snapshots, backup policy | Sensitive data may be exposed or unrecoverable |
| Network | Public IP, NIC and subnet NSGs, effective routes, host firewall, outbound access, private services | Path test, effective rules, firewall policy, flow logs | Internet or lateral exposure increases exploitation impact |
| Identity | Managed identity, Azure RBAC, VM login roles, local privilege, service accounts | Role assignments, token use, local group export | A compromised VM can use its identity to reach cloud resources |
| Monitoring | Activity Log, guest telemetry, security events, diagnostic settings, time sync, alert ownership | Data collection rule, workspace ingestion, detection test | Attack evidence may be absent or too late |
| Recovery | Backup coverage, application consistency, restore procedure, recovery network, test result | Vault policy, job and restore records | Ransomware or destructive change becomes prolonged outage |
PaaS applications
Review supported runtime stacks, TLS and HTTPS-only settings, authentication, access restrictions, private endpoints, VNet integration, deployment credentials, FTP state, managed identities, Key Vault references, configuration slots, remote debugging, client certificates, diagnostic logs, backups where used, and Defender coverage. Confirm that sensitive settings are not copied into an insecure slot or exposed through deployment tooling.
Review hosting plan, runtime support, function authorization level, managed identity, storage-account access, network integration, private endpoints, CORS, secrets, deployment, extension bundles, application dependencies, logging, and scale behavior. Function keys are not a substitute for robust identity and authorization when the workload handles sensitive actions.
Use secure development practices, dependency and secret scanning, code review, API authentication, authorization tests, input validation, rate limits, TLS, logging, and DAST where appropriate. Cloud platform hardening cannot correct insecure application logic or excessive data access.
Test the application through the same edge, identity, network, and API path used by real clients. A PaaS service may have a secure configuration while an old deployment endpoint, alternate hostname, direct origin, staging slot, or leaked credential remains reachable.
Containers and Kubernetes
Start with cluster inventory, ownership, version, region, criticality, data, network model, node pools, and identity integration. Review API server exposure, authorized IP ranges or private access, local account state, Entra authentication, Azure RBAC for Kubernetes or native Kubernetes RBAC, cluster-admin paths, admission controls, policy, secrets, workload identities, and diagnostic settings.
For nodes, review supported operating-system images, automatic upgrades, patching, endpoint and runtime protection, SSH access, disk encryption, scaling, and workload isolation. For pods, review security contexts, root use, privilege escalation, Linux capabilities, host mounts, host networking, resource limits, service accounts, secrets, image tags, health probes, and network policy.
Azure Container Registry needs private or restricted network access, Entra authorization, scoped permissions, managed identities, disabled anonymous access, webhook and token review, image vulnerability assessment, retention, quarantine or approval workflow where used, and logging. Avoid mutable production tags such as `latest`; deploy immutable digests when the pipeline supports it.
Vulnerability prioritization
Use the result to determine containment, patching, configuration change, compensating control, acceptance, and retest priority. Document why a lower-CVSS issue is urgent or why a high-CVSS finding has limited current reachability. Do not suppress a vulnerability merely because a patch is unavailable; evaluate isolation, feature disablement, access restriction, virtual patching, or workload retirement.
Scanning coverage
Can identify software and vulnerability information without deploying an in-guest agent for supported machines and plans. Review coverage, scan timing, encrypted-disk support, permissions, exclusions, freshness, and the relationship to other tools.
EDR and vulnerability-management sensors can add runtime, process, software, exposure, and threat context. Confirm sensor health, onboarding coverage, exclusions, connectivity, and alert ownership.
Authorized credentialed scanners can assess OS and application configuration in depth. Protect scanner credentials, limit privileges, define safe targets and rates, and record failed authentication that reduces scan quality.
Image scans evaluate packages and dependencies at a point in time; runtime security evaluates deployed behavior and current exposure. Include base images, private dependencies, rebuild cadence, and running-image inventory.
SAST, SCA, secret scanning, IaC scanning, DAST, API testing, and manual review find different classes of weakness. None alone proves application security.
Defender recommendations and Azure Policy identify misconfiguration, but direct evidence and scenario testing remain necessary for critical controls and complex architecture.
Remediation and closure
Verify the resource, software, version, exposure, owner, scan timestamp, authentication quality, and whether the finding is duplicated across tools. Do not assign a patch ticket to an image that has already been retired.
Restrict public access, disable the vulnerable feature, isolate the workload, reduce privilege, block exploit traffic, rotate exposed credentials, or scale down the affected component as authorized. Preserve incident evidence when compromise is possible.
Patch, upgrade, rebuild from a trusted image, replace a dependency, correct configuration, change architecture, remove the component, or implement a time-bound compensating control. Fix the golden image and deployment pipeline so the weakness does not return.
Use development and staging where available. Validate application function, performance, integration, monitoring, backup, and rollback. Coordinate restarts and node draining with service owners.
Repeat the original scan or query, confirm the new version or configuration, verify the running image or host, and check that the network and identity exposure changed as intended.
Link the before and after result, change record, deployment artifact, test, owner approval, residual risk, and policy or pipeline control that prevents reintroduction.
Use the Azure security remediation roadmap when findings span teams, dependencies, or change windows.
Implementation support
OC Security Audit can evaluate risk, evidence, attack paths, scanner coverage, and remediation closure. IT Perfection can support relevant Azure administration, endpoint, server, patching, network, backup, and managed IT implementation through managed IT services when operational follow-through is needed.
Retest after patching, image rebuild, network change, identity change, Defender plan change, workload migration, cluster upgrade, application release, or accepted-risk expiration.
Official guidance
Microsoft updates Azure capabilities, portal locations, licensing, defaults, feature status, and prerequisites. Confirm the current product documentation before a production change.
Practical questions
Agentless scanning inspects supported machines without a persistent guest agent, while agent-based and endpoint tools can add runtime, process, sensor, software, and threat context. Coverage and limitations differ.
Evaluate active exploitation, reachability, privilege, asset criticality, existing controls, change risk, and available mitigation. Urgent exposure may require containment before a tested patch or rebuild.
Use trusted base images, dependency and secret scanning, vulnerability assessment, immutable digests, narrow registry access, private connectivity where appropriate, approved pipelines, admission controls, and runtime monitoring.
Microsoft patches the managed platform, while the customer remains responsible for supported runtime selection, application code, dependencies, identity, configuration, network access, deployment, secrets, and logging.
Confirm the running asset or image changed, repeat the original scan or query, verify reachability and identity exposure, test application function, and preserve the deployment and validation evidence.
About the author
Reviewed for practical Azure security, evidence, and remediation guidance by Ali Hassani, CISO, with 25+ years of IT and cybersecurity experience.
This material is for initial guidance only and does not replace a professional cybersecurity audit, compliance assessment, penetration test, or legal/compliance review. Validate configuration, licensing, service availability, architecture, and business impact before production changes.
This website uses essential cookies for security and operation. Optional analytics and advertising cookies help measure site use and outreach. Choose Allow or Deny. You can change your choice at any time.