5. July 2026

Securing Azure Access for Developers with AVD

Developers need fast, flexible access to Azure services. They need to work with code, infrastructure, databases, APIs, storage, DevOps tooling, and cloud-native platforms without unnecessary friction. But from a security perspective, the challenge is not simply granting access, It’s controlling where that access happens, where credentials live, and how private Azure resources are reached.

In many organisations, developer access still relies heavily on laptops, local tooling, home networks, VPNs, stored credentials, and broad network exceptions. That model can work, but it also extends the trusted boundary out to every endpoint. If a device is compromised, misconfigured, lost, or unmanaged, the risk increases significantly.

A better approach is to make the laptop the access device, not the trusted execution environment.

That is where AVD can change the model.

The Developer Access Challenge

The problem is not that developers need access. They absolutely do.

The real challenge is that modern developer access often involves a mix of:

• Different devices
• Different locations
• Different networks
• Local credentials and certificates
• Privileged tools installed on endpoints
• Supplier or contractor access
• Private Azure services that should not be exposed publicly

When each laptop becomes part of the trusted boundary, security teams are forced to manage a much wider risk surface. Every endpoint potentially becomes a place where secrets, access tokens, source code, data extracts, certificates, and privileged tooling can exist.

As highlighted in the deck, the key principle is simple: the developer laptop should be the access device, not the trusted execution environment.

Moving the Trusted Workspace into Azure

With AVD, organisations can move the trusted developer workstation into Azure.

Developers still use their laptop, but the sensitive work happens inside a controlled AVD session. This means Azure Portal access, Azure CLI, PowerShell, Visual Studio Code, database tools, storage tools, Kubernetes tooling, and infrastructure-as-code tooling can all run from a hardened, monitored workspace.

This creates a much stronger security model:

• Centralised control: Session hosts can be hardened, patched, monitored, and managed consistently.
• Identity-first access: Microsoft Entra ID, MFA, Conditional Access, Privileged Identity Management, and RBAC can govern access.
• Reduced endpoint risk: Sensitive tooling, credentials, and data remain inside Azure-hosted sessions.
• Consistent tooling: Developers receive approved tools and baseline configurations without relying on local device setup.
• No inbound RDP exposure: AVD uses a reverse-connect model where session hosts establish outbound connectivity to the AVD service.

The architectural shift is powerful: the developer endpoint becomes a client, while AVD becomes the governed workspace.

Private Access to Azure Services

AVD is not just a remote desktop solution. It can also become a secure access pattern for private Azure resources.

Rather than exposing services publicly or creating broad firewall exceptions for developer laptops, organisations can place AVD session hosts inside a controlled Azure virtual network. From there, developers can access services privately through hub-and-spoke networking, private DNS, routing controls, firewalls, and Private Endpoints.

This model supports secure access to services such as:

• Azure Storage
• Azure SQL
• Key Vault
• Private web apps and APIs
• Private AKS clusters
• Data platforms
• DevOps tooling
• Internal management interfaces

The key phrase from the presentation sums it up well:

The developer laptop connects to AVD, then AVD connects privately to Azure services.

That distinction matters. It means the private network path belongs to the controlled Azure workspace, not to every individual laptop.

Identity-Based Storage Access

Storage access is a common requirement for developers. They may need to work with artefacts, logs, build outputs, data extracts, file shares, or Data Lake content.

A secure model should avoid handing out storage account keys or long-lived secrets wherever possible. Instead, developers should access storage using their Microsoft Entra identity and least-privilege Azure RBAC data roles.

For Blob Storage and Data Lake, this means using Entra ID and Azure RBAC. For Azure Files over SMB, Microsoft Entra Kerberos can support identity-based access, including cloud-only scenarios where a traditional domain controller may no longer be required for authentication and authorisation.

In an AVD context, this becomes even cleaner. Developers sign into a controlled workspace, launch approved tools, and access storage using their own identity — not shared keys.

Delivering Developer Tooling with App Attach

One of the biggest operational challenges with developer environments is tooling.

Different teams need different tools. Different projects need different versions. Cloud engineers, data engineers, AKS engineers, platform teams, and external developers may all require different combinations of:

• Azure CLI
• PowerShell
• Terraform
• Bicep
• Visual Studio Code
• Git
• SQL tools
• Data tooling
• kubectl
• Helm
• SDKs and extensions

If every tool is baked into a golden image, images quickly become bloated, hard to maintain, and difficult to govern.

App Attach helps solve this by separating the base image from the application layer. The base AVD image can remain clean, hardened, and consistent, while developer tools are dynamically attached to the user session based on role, project, or group membership.

That gives organisations a flexible way to deliver the right tools to the right users without creating excessive image sprawl.

A Recommended Secure Access Model

The recommended model has four simple stages:

1. Access Device

The laptop is used to reach AVD. It should not be the primary location for privileged tooling, secrets, keys, or sensitive data.

2. Identity Gate

Access is governed through Microsoft Entra ID, MFA, Conditional Access, Privileged Identity Management, and least-privilege RBAC.

3. Controlled Workspace

Azure tools run from a hardened and monitored AVD session host. This creates a consistent, supportable, and auditable workspace for developers.

4. Private Access

Azure services are accessed using Private Endpoints, private DNS, controlled routing, and network segmentation. This reduces the need for public exposure or broad exceptions for individual developer endpoints.

Security and Productivity Do Not Have to Compete

One of the strongest arguments for this model is that it supports both security and productivity.

From a security perspective, organisations gain a stronger control plane with:

• Microsoft Entra authentication
• MFA and Conditional Access
• Least-privilege RBAC
• PIM for privileged access
• Defender integration
• Central monitoring
• Hardened session hosts
• Network segmentation
• Private Endpoints
• Reduced endpoint exposure

From a productivity perspective, developers gain:

• A consistent workspace
• Faster onboarding
• Approved tooling
• Access to private Azure services
• Fewer local setup issues
• Less dependency on VPN and laptop configuration
• Role-based tool delivery through App Attach

This is not about slowing developers down. It’s about giving them a secure, standardised, and productive place to work.

…and finally

AVD can be much more than a remote desktop platform. Used correctly, it becomes a secure developer access layer for Azure.

The laptop remains the entry point, but the trusted workspace moves into Azure. Developer tools are delivered consistently. Access is governed by identity. Azure services remain private. Security teams gain control and auditability, while developers get a productive environment that supports modern cloud delivery.

In short:

AVD gives developers a secure place to work in Azure. App Attach gives them the right tools when they need them. Entra ID and private networking make sure access is controlled, auditable, and secure.