Azure Security Best Practices - How We Secure Our Azure Infrastructure
Keytos Team |
- Updated: March 4, 2026How We Protect our Azure Infrastructure with Identity Best Practices
As a PKI and Identity provider, we hold ourselves to a higher standard when it comes to identity security. In this blog we will walk you through how we follow Azure security best practices to secure our cloud only infrastructure.
While the image above might seem impressive and it is something all organizations should try to achieve, it is not enough to protect an organization in today’s zero-trust world. To do this we must focus on decreasing surface area and having good visibility into your organization. Here are the key focus areas we have focused on to secure our infrastructure.
Fully Passwordless Azure Infrastructure
While Azure and Entra ID provide many identity security features such as conditional access and risky login detection, no account is truly secure until it no longer has any password to steal. To protect against identity theft, Keytos has gone fully passwordless for our user accounts as well as our machine identities.
While this may seem like a great north-star goal but impossible to achieve in practice, we have found that with the right tools, it is not only possible but also improves productivity.
How to Go Passwordless for User Identities
When it comes to passwordless user authentication, you can either use SmartCard Authentication (CBA) or FIDO2 (passkeys). At Keytos, we use both. The reason behind this is that while FIDO2 has been the industry standard for many years, there are still many cases (even in Entra ID) where it is not accepted as an authentication method. We found that FIDO2 + Entra CBA cover all the scenarios we use at Keytos. We can seamlessly use these two authentication methods by having our users self-onboard to their passwordless identity using EZCMS.
How to Go Passwordless for Machine Identities in Entra ID
Usually when you think of passwords you think of user identities. However, passwords are everywhere, and one of the most dangerous places for passwords is machine passwords. These include connection strings, passwords on Entra ID service principals, and more. To remove nearly all of these passwords, we leveraged Azure Managed Service Identities (MSI), which give an a passwordless identity to all of our Azure infrastructure. Now all of our Azure infrastructure can authenticate to other Microsoft services without the need for any password, and we can rely on Microsoft to manage the security of these identities.
For scenarios where MSIs are not supported (such as cross-tenant authentication), or for when our applications are hosted outside of Azure (such as in customer’s on-premises servers), we use Azure Service Principals with certificate-based authentication. Unlike with MSIs or regular certificate-based authentication, certificate-based authentication for service principals requires you to register each new certificate in Azure before it can be used. We rotate these certificates and prevent certificate expiration related outages by leveraging EZCA’s automatic certificate rotation for Entra ID Applications.
How to Isolate Your User and Machine Identities from your Corporate Identity to Protect Your Azure Resources
At Keytos we run critical services for many large organizations which requires us to step up our game to the highest level of security. While our industry leading passwordless strategy dramatically reduces our surface area, we are going above and beyond by following Microsoft’s identity best practices for identity isolation.
We created a separate, isolated production Entra ID and Azure tenant that has no connection or trust to our corporate tenant. We have separate user accounts, separate Azure subscriptions, and separate passwordless security keys in our dedicated production tenant. That means that if a corporate account gets compromised, the attacker would not have access to our production resources. This isolation also allows us to have stricter conditional access requirements such as smart login scores and device health that would be difficult to enforce if our production resources were in the same tenant as our corporate identities.
How to Prevent Token Theft With Isolated Access to Production Resources with Device Isolation
While identity isolation is a great step on securing your resources, this only protects from identity theft. It doesn’t prevent an attacker from compromising a device and using it to access production resources. If an attacker compromises a device that is already logged in to production resources, they can access those resources without needing to steal any credentials.
To mitigate the risks of malware and other device-based attacks, we have implemented a modern version of the Microsoft Privileged Admin Workstation (PAW) model. Every engineer at Keytos has two devices: a productivity laptop/workstation for corporate tasks such as email and development work, and a separate dedicated laptop/workstation that can only be used to access production resources using their production identity. Only an engineer’s production identity can log in to the production workstation, and vice versa, only their corporate identity can log in to their productivity workstation. This eliminates the risk of an attacker compromising an engineer’s productivity workstation and using it to access production resources, as the production credentials cannot be used on the productivity workstation.
Unlike the original PAW model, instead of leveraging legacy on-premises technology such as domain controllers, we use Microsoft Intune to manage the devices and Entra ID conditional access to attest device health before each login.
What Does This Mean for Our Engineers and Productivity?
One of the main goals of our security posture is to secure our environment without having an impact to our most precious resource, engineering efficiency. We don’t want our security measures to be a bottleneck for our engineers, and we want to make sure they can still do their work without jumping through hoops. With that in mind, we have made sure that our device isolation strategy does not impact our engineers’ productivity. By having two separate devices, our engineers can easily switch between their corporate and production work without any friction. When information needs to be transferred between the two environments, engineers can RDP from their production workstation to their productivity workstation, allowing them to easily transfer files and information between the two environments while still maintaining the security benefits of device isolation.
We also employ modern authentication methods such as Windows Hello for Business to make logging in to productivity workstations as seamless as possible, and we use EZSSH to allow our engineers to easily access Linux production resources without needing to use a password or jump through hoops.
How to Eliminate Standing Access to Production Resources with Just in Time (JIT) Access
Although we are very confident on our secure identity and device isolation strategies, we also believe in a defense-in-depth strategy, and that humans should not access production unless it is necessary. This does not only improve security, but by making access to production harder it also promotes good engineering practices for deployment automation and self-healing features that improve our reliability and productivity. To enforce this, we have implemented no standing access to production. If an engineer needs to access any production resources, they must request access to the resources through Microsoft PIM or through EZSSH for our Linux endpoints.
How to Protect Code Repositories with Just in Time (JIT) Access and Supply Chain Attack Protection
With the reduction of production access and identity strengthening, we have seen hackers shift left on the software supply chain attacks. GitHub, GitLab, and other code hosting platforms have become prime targets. To prevent these attacks and protect our infrastructure, we extend our already secure Entra identity to GitHub for SSO. While this is a great first step to protect our code, it only protects against actions created in the GitHub site. But as we all know, most privileged git activities happen over SSH. To protect our SSH access to GitHub, we use EZSSH for GitHub, giving our engineers just-in-time access to our code bases. This ensures that every time they push or pull code they are doing it from a computer that meets our conditional access policies in Entra ID.
However, DevOps security does not stop when you commit the code. Supply chain attacks are on the rise, including compromising open source build packages used by GitHub Actions. To protect our artifacts from these types of attacks, we use Step Security’s harden-runner to monitor and block these attacks.
How We Enforce Strict Monitoring to Detect Anomalies in Our Azure Environment and SSL Certificates
Following Microsoft’s assume breach mentality, we cannot just rely on our security measures to protect our infrastructure. We also must monitor it and detect any anomalies. Other than using the tools provided by Azure such as Microsoft Sentinel and Microsoft Defender for Cloud, we wanted to take our security to the next level and monitor more events. That is why we created CloudWatcher, a free open-source monitoring solution that will monitor any slight changes in our Azure environment and alert the on call engineer if any changes are detected. As a security company we also follow Google’s recommendation of monitoring certificate transparency logs with EZMonitor, not only protecting us for someone creating SSL certificates for man-in-the-middle attacks, but also other attacks such as the Azure domain takeover attack we discovered a few years ago.
Compliance Excellence
These strict controls have enabled us to meet and exceed compliance requirements for compliance standards respected across the industry, such as SOC 2 type 2, and ISO27001. If you have any questions about how we secure our infrastructure or how we can help you secure yours, schedule a call with our security experts and start your zero-trust journey with Keytos.