Five years ago, I wrote about 10 companies that were killing it with DevOps. Today, all of those enterprises—including Amazon, Walmart, and Netflix—remain household names, not just for consumers, but in the tech community, too.

Since then, who else has emerged as a clear DevOps leader? These 10 organizations are all pushing the boundaries of DevOps, breaking down barriers between development and operations, transforming their companies and their industries—and continuing to do so during a time of global upheaval.

1. Adidas

In 2015, Adidas released the first of its Yeezy sneakers, which were designed in collaboration with Kanye West. Demand for the original shoe—and its many follow-ups—was instantaneous and enormous, with Adidas selling over 2,600 shoes in the space of five seconds. That was great for business, but it presented a huge challenge for IT, which was tasked with ensuring the Adidas’ tech infrastructure didn’t collapse under the strain.

At the start, Adidas wasn’t ready. The site crashed when new Yeezys were announced. Inside the company, developers moaned that they were helpless to fix things and that it could take up to a week even to get a simple virtual machine spun up.

Faced with upset customers and employees, Adidas underwent a massive transformation that embraced cloud-native architecture, Kubernetes, and DevOps and that involved a wholesale cultural shift. A DevOps Cup competition was instrumental in taking the company’s delivery cycle from as slow as six weeks to as fast as five times a day. Today, you can find Adidas’ DevOps Maturity Framework on GitHub.

2. Capital One

In 2010, Capital One was a stodgy financial firm with a dated waterfall development process that was heavily outsourced, a massive in-house data center, and manual build, deployment, and test operations. By 2018, the firm had completed a multi-year journey that culminated in becoming the first major bank to host its banking application on the public cloud, solidifying its reputation as a DevOps leader.

Since that time, the company has been fully reinvented. Today, Capital One is regarded as a leader in agile development and cloud-native infrastructure. It has an almost ruthless devotion to developing its own tools through open-source software—done almost entirely in-house.

The initial goal of Capital One’s DevOps transformation was speed, but, as a financial services firm, security and governance were equally important. The culture of collaboration created through DevOps has been critical to this move, as has a focus on accountability and “fearlessness.” Capital One’s homegrown DevOps dashboard, Hygieia, is highly regarded—and, of course, it’s open source and available to the public, too.

3. Verizon

As the mobile industry began lurching toward 5G, America’s largest wireless carrier embarked on a digital transformation of its own. Verizon 2.0, as it’s known internally, introduced major changes in the business model to make the company more nimble and flexible. These were key qualities needed to enable its successful technical transformation.

Verizon went “public cloud first” in 2016 and embraced immersive DevOps dojos a year after. From there the company worked to modernize its monolithic architecture, embrace open-source tools, and generally become a more agile organization.

Today (or, at least, pre-COVID 19), Verizon has flipped its dojo concept from a six-week-long offsite training session to one where coaches travel to the developers and embed themselves directly within their business units. This has improved the pace of knowledge transfer and allowed for a wider range of training types.

4. CSG International

CSG isn’t a household name, but as a back-end provider of software and services for the telecom industry, it’s a business that touches just about everyone. It primarily provides billing, payment processing, and customer service.

The company launched a broad DevOps reorganization effort in 2016 and integrated the product management function with DevOps in 2018. Modernizing the technology stack has been a goal of the company ever since.

The problem is one of sheer history: In 1994, CSG was spun off from its original owner, First Data, which itself was founded back in 1982. Shards of First Data’s legacy software have endured in the CSG codebase ever since.

But a monumental effort over the last few years—involving revamping its version-control procedures and embracing automated testing—has successfully transformed the enterprise. After doubling down on DevOps, the company is now seeing dramatically improved efficiency, with an 83% reduction in incidents caused by each release.

5. Disney

Disney has been pursuing DevOps aggressively for nearly a decade, revamping its org chart from functional teams to a matrix organization. The company embedded its engineers and managers across various business units and improved cross-functional communications, both of which have radically enhanced the business’s technical capabilities.

The last few years of those efforts were instrumental in powering one of the biggest streaming video launches in recent history, which concluded earlier this year. Almost overnight, Disney+ became a serious competitor to services from Netflix, Amazon, Hulu, and HBO—adding 10 million subscribers in one day, all during a time of incredible global crisis.

6. Northrop Grumman

When your company’s job is to make billion-dollar military aircraft, it’s safe to say that reliability is at the top of the to-do list. With an estimated tens of millions of lines of code powering a single plane, application development is a serious challenge. It can’t be easily addressed through the traditional tools of agile and DevOps, given the potential hazards of pushing a prospective update to aircraft in the field.

Sure enough, Northrop Grumman’s first experiences with DevOps were rocky, in part because it had to work with all manner of government software tools. But it achieved a breakthrough when it embraced “continu-ish integration” and digital twins, and it is now running 15,000 automated test processes each day.

Northrop frequently presents at conferences with its industry mate Lockheed Martin, which has developed and adopted many of the same operating principles.

7. BMW

Now four years into a major DevOps overhaul, BMW has pursued a digital transformation journey as it has migrated its entire firm from a waterfall methodology to a fully agile one. A stodgy organizational culture revamped to support new ways of working.

In 2019, BMW’s “100% BizDevOps” approach began tying project funding to the business value that the project would potentially provide, while bringing microservices and cloud-first architecture into the mix. With 30,000 servers running 5,000 different applications, BMW found the road to success by starting small and taking baby steps toward change rather than attempting to make a wholesale transformation all at once.

8. Optum

Optum is the sister company of UnitedHealthcare, the largest healthcare company in the world. Optum is heavily focused on data management and analytics in the healthcare space. It faced a problem familiar to many large enterprises: Development wanted to move quickly by implementing new features and applications, while operations wanted stability in the apps it was already managing.

Optum embraced DevOps in earnest in 2014 to break down these silos, and the company’s recent metrics have shown that its efforts have proved very successful, with millions of dollars saved every year by reducing mainframe usage alone.

The amount of data managed by Optum and its parent company presented its greatest challenge, with unstandardized data coming at the organization from dozens of sources, all courtesy of thousands of APIs. A massive standardization and modernization effort has seen the creation of a scalable, centralized data platform that allows information to be seamlessly shared across multiple consumers. The approach was borrowed from successful digital transformations in the retail and financial industries.

That’s been a foundational part of a cultural shift that has been effective at finally getting some 160 tech teams on the same page.

9. Nationwide Mutual Insurance

Nationwide began its digital transformation journey in 2009, and since pulling out the stops in 2017, it’s become a poster child for DevOps evangelism and the business successes it can foment. After a wholesale move to agile and distributed development that took three years, the insurer improved code quality by 50% and reduced downtime by a whopping 70%—despite continuing to actively build for its legacy mainframe platforms.

The key has been a bimodal process that lets different groups iterate at different speeds, allowing Nationwide to “move slow and fast at the same time.” Large transactional systems with many dependencies can percolate a bit more methodically, while more visible, customer-facing services (such as mobile apps) are updated far more frequently. This ultimately lets Nationwide more effectively prioritize its tech efforts while giving staff the freedom to experiment.

10. Starbucks

Making coffee isn’t so easy when you have more than 300,000 people involved in the process. Starbucks’ bold move to DevOps began in 2015, and it learned quickly that it needed to balance the desire to constantly push code forward with the need to ensure that code is appropriately tested and ready for deployment. Organizational tweaks within the company were hugely successful, ultimately reducing cycle time by a massive 74%.

One of the most challenging parts of the move to DevOps at Starbucks was the transition of the company’s product leadership to an environment composed of self-managed teams. Working carefully with employees to understand how jobs and responsibilities change after DevOps is adopted is an essential step to smoothing the path forward, the company learned.

Looking ahead

Digital transformation efforts continue to drive enterprises in all industries toward DevOps and agile methodologies, and the payoff from those efforts hasn’t slowed. Even large and very old businesses are finding ways to integrate DevOps thinking with old ways of doing business, integrating legacy operations with cloud-first and open-source initiatives to create innovative operational structures.

As the Covid-19 pandemic continues to challenge traditional ways of operating, watch for these trends to accelerate in the next few years.

Background: Why Monaco Cancelled Its 2020 Baccalaureate Exams

On 3 April 2020, Monaco’s education authority announced the cancellation of final written exams for both the baccalaureate (the school-leaving qualification) and the brevet (the national diploma awarded at the end of lower secondary school). The decision was driven by the disruption caused by the COVID-19 pandemic, which had forced schools to close and students to learn remotely during a prolonged period of confinement.

In place of the traditional high-stakes final exams, both qualifications would be awarded on the basis of continuous assessment — a shift that required detailed guidance from the administration to ensure consistency and fairness.

How Continuous Assessment Would Work for the Baccalaureate

Isabelle Bonnal, Monaco’s Director of National Education, provided further detail on the practical implementation of the new approach. Key points included:

• Grade calculation: Only marks earned in the first two trimesters of the academic year would count toward the final baccalaureate result. Third-trimester grades obtained after schools reopened on 4 May 2020 would not form part of the numerical calculation.
• Teacher commentary: Rather than contributing numerically, progress observed after schools reopened would be recorded as written comments in each student’s school record book (livret scolaire). Teachers would also note attendance and engagement with schoolwork during the confinement period.
• Abolition of the Première oral exam: The oral exam in French language for students in the Première year (the penultimate year of high school) was permanently abolished, replaced by continuous assessment. This change applied not just as a COVID-era exception but as a lasting reform for the Monaco system.

The Role of the Jury

Director Bonnal emphasised that the fundamental structure of the baccalaureate jury would remain unchanged. As in every other year, the diploma would be awarded by a jury convened under the Academy of Nice, chaired by an academic and composed of inspectors and teachers.

The jury’s responsibilities in 2020 included:

• Reviewing each candidate’s livret scolaire (school record book).
• Examining academic results from the first two trimesters of the Terminale (final year), as well as results from the first year (Première).
• Taking into account the qualitative assessments written by classroom teachers.
• Applying a harmonisation process to ensure equal treatment of all candidates, regardless of which school or class they attended — a standard practice designed to correct for grading differences between establishments.

Return to School and Additional Class Openings

Students in the Première and Terminale year groups had already returned to in-person classes from 4 May 2020. Bonnal indicated that the administration was reviewing the possibility of opening additional classes — potentially two to three days per week — in line with steps being taken in France, while continuing to respect health and safety protocols for both students and staff.

The emphasis on in-person assessments delivered by teachers was deliberate: face-to-face observation allowed educators to provide the qualitative commentary that would feed into the jury’s deliberations, giving students credit for their engagement and effort during an exceptionally difficult period.

Key Takeaways

• Monaco’s 2020 baccalaureate was awarded entirely on continuous assessment, using trimester grades and teacher commentary rather than final written exams.
• The abolition of the Première French oral exam was framed as a permanent change, not a temporary measure.
• A jury under the Academy of Nice retained oversight, with a harmonisation step to ensure fairness across candidates.
• The administration balanced the need for meaningful in-person assessment with ongoing public health requirements as schools reopened in May 2020.

Free Single Sign-On Now Available to All Azure AD Subscribers

Microsoft announced that unlimited Single Sign-On (SSO) access is now available at no extra cost to every Azure Active Directory (Azure AD) subscriber, including those on the free tier. Previously, a limit existed on the number of apps that could be assigned to a user for SSO. That limit has been removed.

SSO allows end users to authenticate once and then access multiple applications without repeating the login process for each one. Any organisation holding a subscription to a Microsoft commercial online service — including Azure, Microsoft 365 (Office 365), Dynamics, or Power Platform — can now enable SSO across all their cloud apps, even with the Azure AD Free plan.

The expanded SSO support covers gallery apps and non-gallery apps, and works with OpenID Connect (OIDC), SAML, and password-based SSO protocols.

“Whether you need gallery apps or non-gallery apps, using OIDC, SAML or password SSO, we have removed the limit on the number of apps each user can be assigned for SSO access in Azure AD.”

— Microsoft Azure AD announcement, May 2020

This builds on Microsoft’s earlier move to make multi-factor authentication (MFA) and security defaults free across all Azure AD pricing tiers, meaning every application can now benefit from both SSO and MFA protection at no additional licensing cost.

New Azure AD Features Reaching General Availability

Microsoft also announced several Azure AD capabilities that moved from preview to general availability (GA) — meaning they are now fully supported for production use. Note that some require Azure AD Premium licensing.

Bulk Operations for Users and Groups

IT administrators can now use comma-separated value (CSV) files to perform bulk operations such as importing or exporting users and groups, deleting users, updating group memberships, and downloading user or group data. This significantly reduces the manual overhead of managing large directories.

Report-Only Mode for Conditional Access

The report-only mode for Azure AD Conditional Access allows administrators to evaluate the impact of a Conditional Access policy change before enforcing it in production. This is valuable for change management and reduces the risk of accidentally locking out users.

Continuous Access Evaluation

Continuous Access Evaluation (CAE) extends access control beyond the initial authentication event. It monitors for changed conditions — such as a user account being disabled or a session being revoked — after access has already been granted. At GA, CAE is available for Exchange Online and Microsoft Teams. Microsoft’s implementation is based on a developing standard from the OpenID Foundation.

Combined MFA and Password Reset Registration

A combined registration experience allows end users to set up both multi-factor authentication and self-service password reset (SSPR) in a single workflow. Users can complete this through the My Profile website or the Microsoft Authenticator app on their mobile device, reducing support burden on IT helpdesks.

Token Configuration

Application developers can now use the token configuration feature to specify which optional claims should appear in access tokens, ID tokens, and SAML tokens sent to their applications. This provides greater flexibility for applications that require specific user or tenant attributes at runtime.

SAML Token Encryption

SAML token encryption, an Azure AD Premium feature, is now generally available. While Azure AD already transmits SAML tokens over encrypted HTTPS channels, token-level encryption adds an additional layer of protection by ensuring the token payload itself is encrypted and can only be decrypted by the intended application.

Azure AD Features in Preview

Dynamic Groups Rule Validation

Azure AD’s Dynamic Groups feature automatically adds users to groups based on attribute-based rules. The new rule validation preview lets IT administrators test whether a specific user would be included in a dynamic group under a given rule, before committing the rule to production. This reduces errors in group membership configuration, which has been a common pain point since the feature launched.

Administrative Units

The administrative units preview introduces a way to logically scope administrative permissions within a tenant. An administrative unit acts as a container for Azure AD resources — users and devices — enabling organisations to delegate administration only over specific subsets of their directory.

A typical use case is a large university where different administrators manage different schools. An administrator for the “Business School” administrative unit would only have permission over users and devices in that unit, not the entire directory. This is a meaningful step forward for least-privilege administration in large, complex organisations.

Azure AD B2B and B2C Improvements

Redesigned B2B Collaboration Invitation Emails (GA)

Microsoft updated the invitation emails used in Azure AD B2B collaboration, which govern how external business partners are invited to access shared resources. The redesigned emails are now generally available and are intended to provide external users with clearer context so they can make an informed decision about accepting the invitation.

Invite Internal Users to B2B Collaboration (Preview)

A new preview capability allows administrators to convert existing internal users to B2B guest users, targeting organisations that had previously collaborated with external people without formally classifying them as guests. The conversion retains the user’s existing user ID, user principal name (UPN), group memberships, and app assignments.

SAML-Based Application Support for Azure AD B2C (GA)

Azure AD B2C tenants can now integrate with SAML-based applications at general availability. This means B2C deployments can offer identity providers using OIDC, OAuth, and SAML protocols — including providers such as Salesforce, Facebook, Google, and Active Directory Federation Services (ADFS) — to their end users.

Azure AD and Zero Trust Security

Alongside the feature updates, Microsoft outlined how Azure AD fits into a Zero Trust security model. The core principles of Zero Trust, as stated by Tarek Dawoud, a Microsoft principal program manager, are:

• Verify explicitly — always authenticate and authorise based on all available data points.
• Use least privileged access — limit user access with just-in-time and just-enough-access controls.
• Assume breach — minimise blast radius and segment access; verify end-to-end encryption.

“Azure Active Directory can act as the policy decision point to enforce your access policies based on insights on the user, device, target resource, and environment.”

— Tarek Dawoud, Principal Program Manager, Microsoft

Implementing a full Zero Trust architecture with Azure AD typically requires at minimum Azure AD Premium P1 or P2 licensing, with some advanced scenarios calling for Microsoft 365 E5 licensing. The free-tier SSO and MFA improvements announced in this release do, however, lay a foundation for Zero Trust at no additional cost.

Summary of Key Changes

Licensing requirements shown are approximate based on the announcement. Always verify current licensing requirements in the official Microsoft Azure AD documentation, as tiers and entitlements change over time.

What Is Cloud-Native, and Why Does It Matter for 5G?

Cloud-native is a design philosophy centered on building and operating applications that fully exploit the advantages of cloud computing delivery models—whether those applications run in public clouds, private clouds, or on-premises infrastructure. Rather than simply migrating legacy software to cloud servers, cloud-native demands a fundamental rethinking of how applications are architected, deployed, and managed.

For the 5G wireless industry, adopting cloud-native principles is not a cosmetic upgrade. It represents a structural shift in how network functions are designed, how quickly new services can reach production, and how efficiently operators can scale capacity in response to demand.

5G Americas White Paper on Cloud-Native Networking

In December 2019, industry trade organization 5G Americas published a white paper examining cloud-native concepts as they apply to 5G networks. The paper introduces core cloud-native concepts, explains how they will reshape 5G network architecture, identifies adoption challenges, and proposes reference architectures and recommendations to guide network operators through the transition.

The white paper was co-led by Sam Samuel of Cisco and Milind Gunjan of Sprint, with support from 5G Americas member organizations including AT&T, Ericsson, Nokia, Qualcomm, Samsung, T-Mobile US, Telefónica, and others.

Key Cloud-Native Concepts Relevant to 5G

The white paper highlights several modern cloud computing techniques that are central to a cloud-native 5G architecture:

• Containerization: Packaging network functions as lightweight, portable containers (e.g., using Docker or similar runtimes) that can be deployed and scaled independently across diverse infrastructure.
• Microservices: Decomposing monolithic network functions into smaller, independently deployable services that communicate via well-defined APIs, enabling faster updates and easier fault isolation.
• Control-User Plane Separation (CUPS): Decoupling the control plane (policy and signaling) from the user plane (data forwarding) so each can be scaled and updated independently—a key architectural feature of the 5G core.
• Service Mesh: An infrastructure layer that handles service-to-service communication, providing traffic management, observability, and security without requiring changes to application code.
• Continuous Integration and Continuous Delivery (CI/CD): Automated pipelines that test, validate, and deploy code changes rapidly and reliably, reducing the time between development and production.
• DevOps: A cultural and operational model that breaks down silos between development and operations teams, enabling faster iteration, shared responsibility, and tighter feedback loops.

How Cloud-Native Changes 5G Network Development

Chris Pearson, President of 5G Americas, summarized the business impact:

“Developers are in the process of using fully automated continuous integration to test and push new codes and concepts to production. Cloud Native is going to enable enterprises and the telecom sector to bring newer ideas to production in a reduced time and improved innovation capability.”

Chris Pearson, President, 5G Americas

In practical terms, this means telecom operators can iterate on network features at a pace closer to software companies, rather than on the multi-year upgrade cycles historically associated with hardware-centric telecom infrastructure. New revenue-generating services—network slicing, edge computing, ultra-low-latency APIs for enterprise customers—become operationally feasible when the underlying network functions can be deployed and updated through automated pipelines.

The Open-Source Ecosystem Enabling Cloud-Native 5G

A significant portion of the white paper examines the open-source ecosystem that underpins the cloud-native approach. This ecosystem encompasses:

• Service architectures (such as those defined by 3GPP for the 5G Service-Based Architecture)
• Infrastructure-as-Code (IaC) tools for reproducible, version-controlled environment provisioning
• Automation frameworks for orchestration and lifecycle management of network functions
• CI/CD pipeline tooling for automated testing and deployment
• Monitoring and observability tools for real-time insight into network function health and performance

Projects under organizations such as the Linux Foundation (including ONAP, Kubernetes, and related initiatives) are frequently referenced in industry discussions of cloud-native telecom infrastructure, though specific project endorsements should be verified in the original white paper.

Challenges and Migration Strategies

Adopting cloud-native principles is not straightforward for incumbent network operators. Sam Samuel of Cisco, co-leader of the white paper project, was direct about the complexity involved:

“The road to cloud-native must be broken into phases, as operators will require deploying 5G core networks on a properly configured and controlled Cloud-Native stack. This is a significant task that may require the re-architecting and re-tooling of network functions for cloud-native operation.”

Sam Samuel, Cisco, co-leader of the 5G Americas Cloud-Native white paper

Key challenges the white paper identifies include:

• Legacy network function re-architecture: Many existing network functions were designed for dedicated hardware and require significant engineering effort to containerize and decompose into microservices.
• Operational tooling gaps: Operators must build or acquire CI/CD pipelines, container orchestration expertise (commonly Kubernetes), and observability stacks—capabilities that are new to traditional telecom operations teams.
• Ecosystem maturity: Standards, APIs, and tooling continue to evolve; operators must balance adopting early with the risk of building on specifications that are not yet stable.
• Security posture: Distributed, containerized environments introduce new attack surfaces and require updated security models compared to traditional network architectures.
• Phased migration: Operators must support hybrid environments in which cloud-native and legacy network functions coexist during transition periods.

Milind Gunjan of Sprint, the other co-leader of the project, acknowledged both the opportunity and the patience required:

“Cloud-native technologies will empower organizations to deploy and scale network functions more quickly and generate new services and revenue streams. We’re excited for the industry to focus on building a common, open, cloud-native platform and toolkit that can be easily and effectively adopted. But like all new technology concepts, time is needed for the network function architecture to evolve and the cloud-native ecosystem to mature.”

Milind Gunjan, Sprint, co-leader of the 5G Americas Cloud-Native white paper

Reference Architectures and Recommendations

The white paper draws on reference architectures produced by standards bodies to offer concrete guidance on the path toward cloud-native 5G deployment. It covers:

• The specific requirements of 5G (latency, throughput, network slicing, massive device connectivity) and how cloud-native architectures address each
• Migration strategies for operators moving from 4G/LTE core to a cloud-native 5G core
• Deployment best practices for containerized network functions
• Recommendations for phased adoption to manage risk while building organizational capability

About 5G Americas

5G Americas is an industry trade organization comprising leading telecommunications service providers and equipment manufacturers. Its mission is to advocate for the advancement of LTE and 5G wireless technologies across networks, services, applications, and connected devices throughout the Americas. The organization is headquartered in Bellevue, Washington.

Board of Governors members at the time of publication included: AT&T, Cable & Wireless, Ciena, Cisco, CommScope, Ericsson, Intel, Kathrein, Mavenir, Nokia, Qualcomm Incorporated, Samsung, Shaw Communications Inc., Sprint, T-Mobile US, Inc., Telefónica, and WOM.

Key Takeaways for DevOps and Telecom Engineers

• Cloud-native is not a bolt-on to 5G—it is a prerequisite for the flexibility and speed that 5G’s service promises require.
• Containerization and microservices decomposition of network functions are the foundational technical steps; CI/CD and DevOps practices follow to operationalize them.
• Migration must be phased. No operator will flip a switch from legacy to fully cloud-native overnight.
• The open-source ecosystem (orchestration, IaC, monitoring, pipeline tooling) is maturing rapidly, but gaps remain—operators should track standards body output and open-source project roadmaps closely.
• Security, observability, and organizational change management are as important as the technical architecture choices.

The Customer Is Still the Weakest Link

To date, the majority of well-documented cloud security incidents have been caused by customer-side failures rather than breaches of the cloud service provider’s (CSP’s) own infrastructure. This is an important distinction. CSPs typically have far greater visibility into network configuration and data flows than their customers do — yet they often shield that infrastructure behind proprietary tooling and interfaces, creating a meaningful information asymmetry.

Customers can begin to close this gap by adopting a shared security model with their CSP and by layering in their own zero-trust controls. Before defining solutions, however, it is worth cataloguing the threats that multicloud teams most commonly face.

Common Threats to Cloud Security

1. Misconfiguration and Insufficient Security Settings

Misconfiguration is consistently cited as one of the leading root causes of cloud breaches across both government agencies and commercial organisations. In practice, misconfiguration most often means incorrect Identity and Access Management (IAM) role assignments — giving cloud service accounts more privilege than they need, or failing to restrict access at all.

The canonical example is improperly configured AWS S3 buckets left publicly readable. AWS has since introduced default-block settings and improved its console warnings to help customers avoid this mistake, but misconfigured object storage remains a widespread problem across all major cloud platforms.

2. Insecure APIs

APIs are the primary interface through which customers manage and export cloud data. When APIs are poorly designed, inadequately authenticated, or sourced from third-party vendors with weak security postures, they become high-value targets. Attackers who discover an exposed or weakly authenticated API endpoint can potentially enumerate resources, exfiltrate data, or pivot deeper into a cloud environment without triggering conventional perimeter alerts.

3. Insider Threats — Intentional and Unintentional

Insider threats sit on a wide spectrum. At one end are untrained or negligent employees who hold cloud accounts without appropriate controls — a misconfigured resource or an accidentally shared credential can cascade into a significant incident. At the other end are malicious actors, either employees or external attackers who have obtained insider-level access.

The Capital One breach (2019) is frequently referenced as a case where an attacker exploited a misconfigured Web Application Firewall to assume a cloud IAM role and access sensitive data stored in S3 — illustrating how an outsider can effectively operate as a privileged insider once a foothold is established.

4. Network Misconfiguration

The elasticity of cloud infrastructure — spinning up servers and network segments in minutes — creates significant risk when the people performing those actions do not fully understand the underlying network model. Specific examples include:

• Servers exposed without SSH key authentication or with default/weak credentials
• Unnecessarily open inbound ports creating attack surfaces for DDoS and brute-force campaigns
• Overly permissive rules on cloud-native Security Groups
• Misconfigured Network Access Control Lists (NACLs) that fail to restrict lateral movement

Because cloud environments democratise infrastructure provisioning, it is unsafe to assume that every team member who can click “Launch” also understands the network security implications of what they are deploying.

Four Mitigation Strategies for Multicloud Security

No single control eliminates multicloud risk. The following four strategies, used in combination, can meaningfully reduce an organisation’s attack surface and improve its overall security posture.

1. Zero-Trust Security

Zero trust operates on the principle of “never trust, always verify.” In a multicloud context this is especially relevant: workloads span environments that fall entirely outside the traditional corporate perimeter, making perimeter-based security controls ineffective by design.

Key zero-trust techniques applicable to cloud include:

• Microsegmentation: Dividing cloud workloads into small, independently controlled network segments so that a breach of one workload cannot automatically reach others.
• Identity-aware proxies: Authenticating and authorising every request based on user and device identity rather than network location.
• Single access gateways: Centralising ingress and egress inspection, analogous to the US government’s Trusted Internet Connection (TIC) architecture.
• Mandatory verification of every access request: No implicit trust based on IP address, VPN membership, or previous authentication.

When implemented consistently, zero trust reduces the blast radius of any single compromise and provides greater visibility into who is accessing what across your cloud estate.

2. Cloud Access Security Brokers (CASBs)

A CASB sits between users and cloud services, enforcing security policies — visibility, compliance, data security, and threat protection — across sanctioned and unsanctioned SaaS, IaaS, and PaaS usage. CASBs are particularly useful for discovering shadow IT and enforcing consistent data-loss prevention (DLP) policies across multiple cloud vendors.

Adoption of CASBs has historically been slower than analysts anticipated. According to Gartner’s Hype Cycle reporting referenced in the original Forbes article, CASBs were entering the “trough of disillusionment” at the time of writing (circa 2019–2020). Several independent CASB vendors have since been acquired and folded into broader security platforms. Microsoft, for example, has integrated CASB capabilities directly into Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security).

When evaluating a CASB, consider whether it provides native integrations with each cloud platform in your estate, and whether it will be maintained as a discrete product or absorbed into a larger suite.

3. Workforce Training Tailored to Multicloud Environments

Cloud migration plans frequently budget for tooling and architecture but under-invest in people. Teams trained exclusively on one CSP’s console and security model can introduce risk when the organisation adds a second or third cloud platform, because security assumptions from AWS do not map directly onto Azure or Google Cloud — and vice versa.

Effective multicloud security training should cover:

• The shared responsibility model as it applies to each CSP in use
• IAM fundamentals and least-privilege principles specific to each platform
• Safe storage and API configuration practices across vendors
• Incident recognition and escalation procedures for cloud-native environments

Training should be treated as a continuous programme, not a one-time onboarding exercise, given how rapidly CSP feature sets and security controls evolve.

4. Choosing the Right Partners and Integrators

In a fast-moving cloud ecosystem, vendor and integrator selection has long-term security implications. Partners who have worked across multiple CSPs — and who have direct experience with regulated industries or public-sector requirements — bring institutional knowledge that is difficult to build internally in a short timeframe.

For federal agencies in particular, working with integrators who hold relevant certifications (FedRAMP authorisation experience, for example) and who understand compliance frameworks such as NIST SP 800-53 is critical. The same principle applies to commercial organisations operating in regulated sectors such as healthcare or financial services.

Partner selection criteria should include demonstrated multicloud experience, a clear security methodology, and a track record of working within shared responsibility frameworks — not just technical delivery capability.

Looking Ahead: Shared Responsibility at Scale

As enterprises operate across increasingly complex combinations of multicloud, hybrid cloud, and on-premises infrastructure, the shared security model becomes harder to maintain consistently. The information asymmetry between CSPs and their customers remains a structural challenge, and closing it requires CSPs to be more proactive about educating customers on risk — not just providing the tools to address it.

In the meantime, organisations that combine zero-trust architecture, CASB-based visibility, ongoing workforce education, and carefully selected partners will be meaningfully better positioned than those relying on any single control in isolation.

Original source: Forbes.com. This article summarises and expands on the key recommendations from that piece for a DevOps and cloud engineering audience.