Security and Compliance for Mendix on Azure
Last modified: November 1, 2025
Security and Compliance
Compliance Frameworks
Every release of Mendix on Azure is automatically assessed against selected compliance frameworks using Azure Policy. Currently this asssessment is limited to SOC2, but this will be extended in future versions based on customer demand.
SOC 2 Type 2 Compliance
The automatic SOC2 assessment currently has identified the following compliance deviations which are accepted:
| Policy | Acceptance Rationale |
|---|---|
| Azure Container Registry: Container registries should be encrypted with a customer-managed key | The standard Microsoft key is used instead to ease adoption of the product. |
| AKS - cluster resource: Azure Policy Add-on for Kubernetes service (AKS) should be installed and enabled on your clusters | The cluster is deployed and managed by Mendix, so this policy is not needed. |
| AKS - cluster resource: Azure Kubernetes Service clusters should have Defender profile enabled | This is not automated for cost-saving reasons. |
| AKS - cluster VNET: All Internet traffic should be routed via your deployed Azure Firewall | This is not automated, but customers can deploy their own Firewall if required. |
| Storage Account: Storage accounts should use customer-managed key for encryption | The cluster is deployed and managed by Mendix, so this is not needed. |
Access to Customer Environments by Mendix
Mendix accesses customer environments securely by leveraging native Azure capabilities and adhering to Microsoft's best practices:
- Access is provided through cross-tenant access, a secure Azure-native mechanism.
- The majority of access operations are automated and performed programmatically at scale using infrastructure as code, limiting manual human intervention to exceptional cases.
- All network connectivity between Mendix and customer environments utilizes private links, ensuring communication is not exposed to the public internet.