JetBlue said on June 5, 2026, that it has adopted Azure Firewall as a central security control for its growing Microsoft Azure environment, routing workloads such as virtual machines and Azure Kubernetes Service clusters through managed cloud-native firewalls. The move is not just a product endorsement; it is a useful snapshot of where enterprise cloud security is heading. For large regulated organizations, the firewall is no longer a box at the edge of the data center. It is becoming policy, automation, identity, audit trail, and blast-radius management wrapped into one operational discipline.
The obvious reading of Microsoft’s customer story is simple: JetBlue chose Azure Firewall over a third-party network virtual appliance because it wanted a managed service that integrated cleanly with Azure. That is true, but it undersells the more interesting point. JetBlue’s problem was not merely how to inspect packets in the cloud; it was how to keep security controls from becoming the new bottleneck as the airline modernized.
Airlines are peculiar technology companies. Their public identity is built around routes, fares, cabins, loyalty programs, and punctuality, but their operational reality depends on an immense mesh of software systems that must behave predictably under pressure. Booking, payments, airport operations, crew systems, customer notifications, and flight-adjacent workflows all sit inside a risk environment where downtime, confusion, and weak controls quickly become more than ordinary IT failures.
That is why JetBlue’s framing matters. Ameen Riaz Sherali, a senior engineering manager at the airline, tied customer trust directly to safety and described compliance as a set of guardrails for architecture. This is not the usual “cloud transformation” language of faster releases and elastic scale. It is the language of an industry where security architecture has to satisfy auditors, regulators, engineers, and passengers who will never know the firewall exists unless something goes wrong.
The airline’s Azure migration moved it from on-premises VMware infrastructure toward a hybrid cloud architecture. Along the way, JetBlue adopted services such as Azure Kubernetes Service, Azure Application Gateway, Azure Key Vault, Azure Cosmos DB, and Azure Database for PostgreSQL. That stack is recognizably modern, but it also multiplies the number of places where traffic, secrets, service dependencies, and policy decisions must be governed.
But the cloud changes the failure mode. In a data center, a monolithic firewall may be painful, expensive, and politically powerful, but it is at least operating in a relatively bounded topology. In Azure, where teams can provision new workloads, subnets, routes, Kubernetes clusters, and application components through code, that same monolithic firewall can become a sprawling rule warehouse.
JetBlue appears to have learned this the hard way. Microsoft’s account says the airline initially used a single centralized firewall model carried over from its data center days. A routine configuration change later produced erratic behavior across the environment, with traffic being inconsistently blocked or allowed.
The quoted number is the kind that makes network engineers wince: 144,000 unique source-and-destination rules, against a limit of 20,000. The incident reportedly affected all 450 applications running in the environment. Even if the applications themselves were healthy, the shared firewall had become a concentrated point of operational fragility.
That is the uncomfortable lesson for cloud adopters. A central security service can simplify governance right up until it concentrates too much complexity in one place. The answer is not to abandon central control, but to design it with segmentation, automation, and bounded failure in mind.
The counterargument is operational. Running network virtual appliances in the cloud means managing virtual machines, operating system patching, software upgrades, capacity planning, high availability, licensing, and vendor coordination. Some organizations are willing to pay that price for specialized features or cross-cloud consistency. JetBlue decided the trade was not attractive enough.
Sherali’s cost observation is especially telling. Once the team accounted for virtual machines, infrastructure, and license management, the external firewall option did not look meaningfully cheaper. The comparison was not simply list price versus list price. It was total operational burden versus a managed service integrated into the cloud platform.
That is the pitch Azure Firewall has been refining for years. It is a cloud-native, stateful firewall service with built-in high availability and scaling, designed to sit inside Azure networking rather than beside it. Its value is not that it makes firewall policy magically simple. Its value is that it lets enterprises move a large part of the undifferentiated firewall plumbing to Microsoft.
The most important cloud security control is often the one your team does not have to babysit at 2 a.m. Patch management, platform availability, and scaling are not glamorous features, but they are exactly the sort of operational chores that decide whether security architecture improves resilience or quietly becomes another fragile workload.
But Kubernetes also makes network security more dynamic. Pods come and go. Services depend on registries, APIs, identity providers, monitoring endpoints, package repositories, and cloud control planes. A traditional allowlist mindset can buckle under that churn if teams try to express every modern application dependency as a hand-maintained rule set.
Azure’s own guidance reflects this reality. AKS clusters need controlled outbound access to maintain node operations, pull images, communicate with required services, and keep the cluster healthy. In production, unrestricted egress is a weak default, but overly blunt egress blocking can break the platform that hosts the applications.
That is where a managed firewall becomes less of a perimeter device and more of a cloud operations component. JetBlue routes compute resources, including VMs and AKS clusters, through Azure Firewall using user-defined routes. In plain terms, traffic leaves workloads through an enforcement point where policy, logging, and inspection can be applied consistently.
For WindowsForum readers who spend more time with endpoints and servers than airline-scale cloud networks, this is the cloud equivalent of forcing important traffic through a known chokepoint — but with one crucial difference. The chokepoint itself must be deployed, updated, governed, and scaled as code. Otherwise, the firewall becomes the slowest-moving part of the platform.
Portal-driven firewall administration can work in small environments, but it becomes risky when hundreds of applications depend on shared policy. Manual changes are harder to review, harder to reproduce, and harder to roll back. In regulated environments, they are also harder to explain.
By moving firewall definitions into code, JetBlue gets version history, review workflows, reusable modules, and state management. Sherali’s comment that a mistakenly deleted firewall could be recreated with its previous configuration captures the practical appeal. This is not infrastructure as code as conference-stage ideology. It is disaster recovery for configuration itself.
That shift also changes the politics of security. Instead of a shadowy firewall team making opaque changes in a console, policy can move through pull requests, approvals, and commits. The review trail becomes part of the control. Engineers may still disagree about rules, but the disagreement is attached to a visible artifact.
There is a lesson here for administrators far outside the airline industry. The cloud does not eliminate configuration drift; it industrializes it unless teams adopt a disciplined workflow. A firewall policy that cannot be reviewed like software is increasingly out of place in an environment where the applications it protects are deployed like software.
In the old model, a bad or risky change could ripple across the whole Azure environment. In the new model, changes are more likely to affect only the applications that route through a specific firewall. That is a classic blast-radius reduction strategy, applied to network security rather than compute or storage.
This is where cloud-native architecture often departs from the instincts of traditional enterprise security. The data center worldview often rewarded consolidation: one big device, one big policy set, one heavily controlled perimeter. Cloud architecture tends to reward repeatable patterns: many smaller units, governed centrally, deployed consistently, and isolated where practical.
Landing zones fit that model. They give organizations a way to standardize networking, identity, logging, policy, and subscription boundaries while still letting application teams operate within defined lanes. A firewall instance tied to an application environment is not merely a security appliance; it is part of that environment’s contract with the platform team.
JetBlue’s experience also punctures a common myth: cloud-native does not mean laissez-faire. The airline is not letting every application team invent its own network security model. It is pushing toward dedicated firewall instances while maintaining centralized governance. That is not less control. It is control expressed through architecture rather than one giant rule table.
A cloud firewall that can centralize logs, enforce outbound policies, and integrate with Azure identity controls gives compliance teams something concrete to work with. It does not, by itself, make an organization compliant. No serious security practitioner would claim that. But it can provide the enforcement and evidence layers that auditors expect to see around sensitive systems.
This is why the managed-service decision matters beyond engineering convenience. If Microsoft operates the underlying firewall service, JetBlue’s team can focus more of its attention on policy design, application segmentation, access control, and change governance. Those are the controls that map more directly to risk.
There is also an identity angle. Azure Firewall’s integration with Azure role-based access control means firewall administration can follow the same governance patterns as other Azure resources. Who can change policy, who can review it, and who can deploy it become questions that fit into a broader access model rather than a separate appliance login ritual.
For highly regulated companies, that consistency is not just neat. It reduces the number of places where exceptional access models can hide. A cloud environment with ten different administrative planes is a cloud environment with ten different ways to lose track of accountability.
That narrative is powerful because it speaks to a real anxiety among enterprise buyers. Cloud security used to be framed as a question of whether the cloud could be trusted. Now the more common question is whether organizations can operate cloud security at the speed and scale their own developers demand. Microsoft wants Azure Firewall to be seen as part of that answer.
There is vendor positioning here, and readers should treat it as such. Microsoft is highlighting a successful customer deployment, not publishing a neutral comparative study of every firewall option on Azure. Third-party firewalls remain important in many environments, especially where companies need vendor-specific inspection features, cross-cloud policy uniformity, or deep integration with existing security operations tooling.
But the JetBlue example still says something meaningful about market direction. The more enterprises standardize on cloud-native application platforms, the harder it becomes to justify security tools that do not participate cleanly in that platform’s identity, automation, routing, logging, and deployment models. Feature depth still matters, but operational fit increasingly matters just as much.
In other words, the firewall market is not just competing on packets anymore. It is competing on lifecycle.
That pattern shows up across Microsoft’s stack. Windows Server workloads move into Azure virtual machines or Azure Stack-adjacent models. Endpoint policy shifts toward Intune. Identity centers around Entra ID. Security telemetry flows into Defender and Sentinel. The firewall, long a symbol of vendor-neutral infrastructure control, is being absorbed into the same managed platform logic.
This does not mean every organization should default to Azure Firewall. It does mean Windows-centric IT teams need to understand cloud networking as part of their professional terrain. The old boundary between “server admin” and “network security team” is less clean when a line of Terraform can alter routes, firewall rules, and application reachability.
The skill set is changing accordingly. Administrators need to read route tables, understand egress dependencies, evaluate managed identities, review infrastructure-as-code changes, and know how platform services log security events. They do not all need to become network architects, but they can no longer treat cloud networking as someone else’s appliance rack.
JetBlue’s experience with the 144,000-rule situation is a warning in miniature. Cloud platforms make it easy to accumulate configuration until it becomes ungovernable. The fix was not a heroic troubleshooting session; it was an architectural change. That is the kind of lesson that applies equally to firewall policies, Group Policy objects, Intune configuration profiles, conditional access rules, and Kubernetes manifests.
Security teams have long been rewarded for adding controls. Another rule, another appliance, another approval, another exception process. In the cloud, that additive model can become self-defeating because the environment changes too quickly for manual complexity to remain accurate.
JetBlue’s Azure Firewall approach is not simplistic. It still involves routing, policies, multiple firewall instances, AKS considerations, compliance needs, Terraform modules, and approval workflows. But it tries to make the recurring parts repeatable and the risky parts reviewable.
That is a more modern definition of security maturity. The goal is not to make the diagram look intimidating. The goal is to make the system understandable enough that engineers can change it safely, auditors can verify it, and operators can recover it when something breaks.
This is where managed cloud security services earn their keep. They do not remove the need for expertise. They redirect expertise away from maintaining the scaffolding and toward designing the policy. For many enterprises, that is a better use of scarce talent.
JetBlue’s Cloud Firewall Story Is Really a Governance Story
The obvious reading of Microsoft’s customer story is simple: JetBlue chose Azure Firewall over a third-party network virtual appliance because it wanted a managed service that integrated cleanly with Azure. That is true, but it undersells the more interesting point. JetBlue’s problem was not merely how to inspect packets in the cloud; it was how to keep security controls from becoming the new bottleneck as the airline modernized.Airlines are peculiar technology companies. Their public identity is built around routes, fares, cabins, loyalty programs, and punctuality, but their operational reality depends on an immense mesh of software systems that must behave predictably under pressure. Booking, payments, airport operations, crew systems, customer notifications, and flight-adjacent workflows all sit inside a risk environment where downtime, confusion, and weak controls quickly become more than ordinary IT failures.
That is why JetBlue’s framing matters. Ameen Riaz Sherali, a senior engineering manager at the airline, tied customer trust directly to safety and described compliance as a set of guardrails for architecture. This is not the usual “cloud transformation” language of faster releases and elastic scale. It is the language of an industry where security architecture has to satisfy auditors, regulators, engineers, and passengers who will never know the firewall exists unless something goes wrong.
The airline’s Azure migration moved it from on-premises VMware infrastructure toward a hybrid cloud architecture. Along the way, JetBlue adopted services such as Azure Kubernetes Service, Azure Application Gateway, Azure Key Vault, Azure Cosmos DB, and Azure Database for PostgreSQL. That stack is recognizably modern, but it also multiplies the number of places where traffic, secrets, service dependencies, and policy decisions must be governed.
The Old Data Center Pattern Did Not Survive Contact With Azure
Enterprises often carry their old infrastructure instincts into the cloud, and sometimes those instincts are useful. A firewall as a central enforcement point is one of the oldest and most durable patterns in enterprise computing. If everything must pass through a known control plane, security teams can inspect, log, block, and explain what happened.But the cloud changes the failure mode. In a data center, a monolithic firewall may be painful, expensive, and politically powerful, but it is at least operating in a relatively bounded topology. In Azure, where teams can provision new workloads, subnets, routes, Kubernetes clusters, and application components through code, that same monolithic firewall can become a sprawling rule warehouse.
JetBlue appears to have learned this the hard way. Microsoft’s account says the airline initially used a single centralized firewall model carried over from its data center days. A routine configuration change later produced erratic behavior across the environment, with traffic being inconsistently blocked or allowed.
The quoted number is the kind that makes network engineers wince: 144,000 unique source-and-destination rules, against a limit of 20,000. The incident reportedly affected all 450 applications running in the environment. Even if the applications themselves were healthy, the shared firewall had become a concentrated point of operational fragility.
That is the uncomfortable lesson for cloud adopters. A central security service can simplify governance right up until it concentrates too much complexity in one place. The answer is not to abandon central control, but to design it with segmentation, automation, and bounded failure in mind.
Azure Firewall Won By Removing Work, Not By Adding Features
JetBlue considered third-party network virtual appliances, a familiar option for enterprises with existing firewall vendors, operational playbooks, and security team expertise. The argument for that route is easy to understand. If a company already trusts a vendor’s firewall in the data center, extending that model into Azure can look like the safest political and technical choice.The counterargument is operational. Running network virtual appliances in the cloud means managing virtual machines, operating system patching, software upgrades, capacity planning, high availability, licensing, and vendor coordination. Some organizations are willing to pay that price for specialized features or cross-cloud consistency. JetBlue decided the trade was not attractive enough.
Sherali’s cost observation is especially telling. Once the team accounted for virtual machines, infrastructure, and license management, the external firewall option did not look meaningfully cheaper. The comparison was not simply list price versus list price. It was total operational burden versus a managed service integrated into the cloud platform.
That is the pitch Azure Firewall has been refining for years. It is a cloud-native, stateful firewall service with built-in high availability and scaling, designed to sit inside Azure networking rather than beside it. Its value is not that it makes firewall policy magically simple. Its value is that it lets enterprises move a large part of the undifferentiated firewall plumbing to Microsoft.
The most important cloud security control is often the one your team does not have to babysit at 2 a.m. Patch management, platform availability, and scaling are not glamorous features, but they are exactly the sort of operational chores that decide whether security architecture improves resilience or quietly becomes another fragile workload.
Kubernetes Made Egress Control A First-Class Problem
JetBlue’s enthusiasm for AKS is another key part of the story. The airline moved many workloads into containerized environments, and Sherali said the team likes Kubernetes in general. That preference is hardly surprising. Kubernetes gives large engineering organizations a common substrate for deployment, scaling, service discovery, and application lifecycle management.But Kubernetes also makes network security more dynamic. Pods come and go. Services depend on registries, APIs, identity providers, monitoring endpoints, package repositories, and cloud control planes. A traditional allowlist mindset can buckle under that churn if teams try to express every modern application dependency as a hand-maintained rule set.
Azure’s own guidance reflects this reality. AKS clusters need controlled outbound access to maintain node operations, pull images, communicate with required services, and keep the cluster healthy. In production, unrestricted egress is a weak default, but overly blunt egress blocking can break the platform that hosts the applications.
That is where a managed firewall becomes less of a perimeter device and more of a cloud operations component. JetBlue routes compute resources, including VMs and AKS clusters, through Azure Firewall using user-defined routes. In plain terms, traffic leaves workloads through an enforcement point where policy, logging, and inspection can be applied consistently.
For WindowsForum readers who spend more time with endpoints and servers than airline-scale cloud networks, this is the cloud equivalent of forcing important traffic through a known chokepoint — but with one crucial difference. The chokepoint itself must be deployed, updated, governed, and scaled as code. Otherwise, the firewall becomes the slowest-moving part of the platform.
The Real Firewall Was The Pull Request
One of the strongest parts of JetBlue’s approach is its move toward infrastructure as code. The company is using Terraform and GitHub-based workflows to define and maintain firewall infrastructure and policies. That matters because the operational unit of security is no longer just a rule; it is the change process around the rule.Portal-driven firewall administration can work in small environments, but it becomes risky when hundreds of applications depend on shared policy. Manual changes are harder to review, harder to reproduce, and harder to roll back. In regulated environments, they are also harder to explain.
By moving firewall definitions into code, JetBlue gets version history, review workflows, reusable modules, and state management. Sherali’s comment that a mistakenly deleted firewall could be recreated with its previous configuration captures the practical appeal. This is not infrastructure as code as conference-stage ideology. It is disaster recovery for configuration itself.
That shift also changes the politics of security. Instead of a shadowy firewall team making opaque changes in a console, policy can move through pull requests, approvals, and commits. The review trail becomes part of the control. Engineers may still disagree about rules, but the disagreement is attached to a visible artifact.
There is a lesson here for administrators far outside the airline industry. The cloud does not eliminate configuration drift; it industrializes it unless teams adopt a disciplined workflow. A firewall policy that cannot be reviewed like software is increasingly out of place in an environment where the applications it protects are deployed like software.
Smaller Firewalls Made The Platform Safer
JetBlue’s move away from a single monolithic firewall toward multiple firewall instances aligned with landing zones is the architectural pivot in the story. The point is not that many firewalls are automatically better than one. The point is that the scope of failure should match the scope of responsibility.In the old model, a bad or risky change could ripple across the whole Azure environment. In the new model, changes are more likely to affect only the applications that route through a specific firewall. That is a classic blast-radius reduction strategy, applied to network security rather than compute or storage.
This is where cloud-native architecture often departs from the instincts of traditional enterprise security. The data center worldview often rewarded consolidation: one big device, one big policy set, one heavily controlled perimeter. Cloud architecture tends to reward repeatable patterns: many smaller units, governed centrally, deployed consistently, and isolated where practical.
Landing zones fit that model. They give organizations a way to standardize networking, identity, logging, policy, and subscription boundaries while still letting application teams operate within defined lanes. A firewall instance tied to an application environment is not merely a security appliance; it is part of that environment’s contract with the platform team.
JetBlue’s experience also punctures a common myth: cloud-native does not mean laissez-faire. The airline is not letting every application team invent its own network security model. It is pushing toward dedicated firewall instances while maintaining centralized governance. That is not less control. It is control expressed through architecture rather than one giant rule table.
Compliance Rewards Boring Architecture
The regulatory backdrop is not decorative. JetBlue operates in a world shaped by SOC obligations, PCI DSS requirements for payment systems, and aviation oversight from agencies such as the TSA and FAA. Those frameworks differ in scope and purpose, but they all increase the value of auditability, repeatability, and clear operational boundaries.A cloud firewall that can centralize logs, enforce outbound policies, and integrate with Azure identity controls gives compliance teams something concrete to work with. It does not, by itself, make an organization compliant. No serious security practitioner would claim that. But it can provide the enforcement and evidence layers that auditors expect to see around sensitive systems.
This is why the managed-service decision matters beyond engineering convenience. If Microsoft operates the underlying firewall service, JetBlue’s team can focus more of its attention on policy design, application segmentation, access control, and change governance. Those are the controls that map more directly to risk.
There is also an identity angle. Azure Firewall’s integration with Azure role-based access control means firewall administration can follow the same governance patterns as other Azure resources. Who can change policy, who can review it, and who can deploy it become questions that fit into a broader access model rather than a separate appliance login ritual.
For highly regulated companies, that consistency is not just neat. It reduces the number of places where exceptional access models can hide. A cloud environment with ten different administrative planes is a cloud environment with ten different ways to lose track of accountability.
Microsoft Gets A Useful Case Study At A Convenient Time
Microsoft, naturally, would like enterprises to see JetBlue’s decision as evidence that Azure-native security services are mature enough for serious, regulated workloads. This customer story gives Redmond a clean narrative: a major airline modernizes on Azure, considers third-party firewalls, chooses Azure Firewall, adopts infrastructure as code, and improves operational visibility.That narrative is powerful because it speaks to a real anxiety among enterprise buyers. Cloud security used to be framed as a question of whether the cloud could be trusted. Now the more common question is whether organizations can operate cloud security at the speed and scale their own developers demand. Microsoft wants Azure Firewall to be seen as part of that answer.
There is vendor positioning here, and readers should treat it as such. Microsoft is highlighting a successful customer deployment, not publishing a neutral comparative study of every firewall option on Azure. Third-party firewalls remain important in many environments, especially where companies need vendor-specific inspection features, cross-cloud policy uniformity, or deep integration with existing security operations tooling.
But the JetBlue example still says something meaningful about market direction. The more enterprises standardize on cloud-native application platforms, the harder it becomes to justify security tools that do not participate cleanly in that platform’s identity, automation, routing, logging, and deployment models. Feature depth still matters, but operational fit increasingly matters just as much.
In other words, the firewall market is not just competing on packets anymore. It is competing on lifecycle.
Windows Administrators Should Read This As A Platform Warning
At first glance, JetBlue’s Azure Firewall deployment may seem distant from the concerns of a Windows admin managing endpoints, file servers, Intune policies, or hybrid identity. But the underlying pattern is familiar: Microsoft is pulling more operational control into managed cloud services, and enterprises are choosing simplicity when the alternative is bespoke infrastructure maintenance.That pattern shows up across Microsoft’s stack. Windows Server workloads move into Azure virtual machines or Azure Stack-adjacent models. Endpoint policy shifts toward Intune. Identity centers around Entra ID. Security telemetry flows into Defender and Sentinel. The firewall, long a symbol of vendor-neutral infrastructure control, is being absorbed into the same managed platform logic.
This does not mean every organization should default to Azure Firewall. It does mean Windows-centric IT teams need to understand cloud networking as part of their professional terrain. The old boundary between “server admin” and “network security team” is less clean when a line of Terraform can alter routes, firewall rules, and application reachability.
The skill set is changing accordingly. Administrators need to read route tables, understand egress dependencies, evaluate managed identities, review infrastructure-as-code changes, and know how platform services log security events. They do not all need to become network architects, but they can no longer treat cloud networking as someone else’s appliance rack.
JetBlue’s experience with the 144,000-rule situation is a warning in miniature. Cloud platforms make it easy to accumulate configuration until it becomes ungovernable. The fix was not a heroic troubleshooting session; it was an architectural change. That is the kind of lesson that applies equally to firewall policies, Group Policy objects, Intune configuration profiles, conditional access rules, and Kubernetes manifests.
Simplicity Is Now A Security Feature
The most interesting quote in Microsoft’s story is Sherali’s observation that some data center thinking equated complexity with security, while cloud thinking often moves in the opposite direction. That deserves to be taken seriously. Complexity can create defense in depth, but it can also create blind spots, brittle dependencies, and change fear.Security teams have long been rewarded for adding controls. Another rule, another appliance, another approval, another exception process. In the cloud, that additive model can become self-defeating because the environment changes too quickly for manual complexity to remain accurate.
JetBlue’s Azure Firewall approach is not simplistic. It still involves routing, policies, multiple firewall instances, AKS considerations, compliance needs, Terraform modules, and approval workflows. But it tries to make the recurring parts repeatable and the risky parts reviewable.
That is a more modern definition of security maturity. The goal is not to make the diagram look intimidating. The goal is to make the system understandable enough that engineers can change it safely, auditors can verify it, and operators can recover it when something breaks.
This is where managed cloud security services earn their keep. They do not remove the need for expertise. They redirect expertise away from maintaining the scaffolding and toward designing the policy. For many enterprises, that is a better use of scarce talent.
The JetBlue Lesson Fits In A Carry-On
JetBlue’s Azure Firewall deployment is not a universal blueprint, but it is a compact case study in what cloud security modernization actually looks like when the marketing gloss is stripped away. The airline did not merely “move to the cloud.” It ran into scale, complexity, rule growth, operational overhead, and compliance pressure — then adjusted its architecture.- JetBlue selected Azure Firewall as its primary egress control point for Azure workloads, including virtual machines and AKS clusters.
- The airline chose a managed Azure-native service partly to avoid the operational burden of running third-party firewall appliances in virtual machines.
- A single centralized firewall model became difficult to operate at scale after rule growth reportedly reached 144,000 unique source-and-destination combinations.
- JetBlue’s move to multiple firewall instances reduced the blast radius of configuration changes across its Azure application estate.
- Terraform and GitHub workflows made firewall policy part of a version-controlled change process rather than a manually maintained portal artifact.
- The larger lesson is that cloud security depends as much on governance, automation, and recoverability as it does on inspection features.
References
- Primary source: Microsoft
Published: 2026-06-05T21:12:07.849909
Loading…
www.microsoft.com