Cloud default settings make deployment easy. They do not automatically make your environment secure.
Cloud service providers increasingly market their platforms as secure by default, implying that environments start from a hardened baseline that resists common attacks. In reality, default configurations are built for rapid adoption and broad compatibility, not for the specific threat models, regulatory demands, or abuse scenarios unique to your organization.
This means that the responsibility for actually closing dangerous security holes falls not on the provider but on the organization using the platform. That gap is where convenience becomes liability.
Why these defaults exist
Default cloud configurations are not oversights, but deliberate design decisions made to facilitate adoption and usability. Cloud services are expected to work immediately upon enabling, without the need for lengthy setup, testing, or integrations. Security, by its very nature, introduces a degree of friction that can work against the immediacy that cloud services advertise and customers expect.
Strong controls need context and specificity that cloud providers can’t assume across millions of customers that each have their own needs. Default settings, therefore, end up occupying a middle ground. They are set up to be just secure enough to avoid most dangers, yet permissive enough to prevent stalled functionality and frustration.
The problem is that most cloud environments are never customized beyond that baseline.
Why defaults rarely get revisited
Many insufficient default configurations go overlooked simply because no one actively chose them in the first place. There may be no documentation detailing their calibration because they came pre-packaged.
Once a service is up and running, attention also naturally shifts to business operations and momentum. Defaults quickly become invisible, never questioned until a failure forces an inspection.
Controls, logs, and policies appear enabled, but they were never tweaked for specific use cases or to prevent abuse of legitimate functionality. This causes systems to look and feel protected while they are, in fact, highly exploitable.
Attackers are familiar with this oversight and exploit the predictable nature of default settings. When thousands of organizations deploy cloud services almost exactly the same way, exploitation becomes both easy and repeatable.
Examples of default danger
Identity
Vulnerable cloud identity systems are especially dangerous, as compromised identities tend to grant instant access across the environment.
In Microsoft’s ecosystem, for example, Entra ID sits at the center of nearly every service. Email, Teams, SharePoint, Azure resources, and management interfaces all rely on identity rather than network segmentation to keep malicious actors from moving around within systems.
Microsoft secures the underlying identity platform itself; its Conditional Access policies, role assignments, device trust rules, and logging must be explicitly defined to provide protection in ways customers can actually depend on.
Non-human identities used for automation and integration also frequently operate with long-lived permissions and almost no oversight. When compromised, they provide stealthy persistence that blends into normal application behavior.
Token abuse
Modern cloud attacks heavily exploit tokens to succeed.
Access tokens, refresh tokens, and Primary Refresh Tokens (PRTs) enable seamless authentication across services. PRTs, in particular, allow access tied to both a user and a device. When attackers steal them, they can request new tokens freely without triggering any alarm bells.
This doesn’t require exploiting software vulnerabilities or bugs. Threat actors only need an understanding of how defaults handle trust and token lifecycle to find ways to get a foot in the door.
Collaboration platforms
The same dangers extend into collaboration services such as SharePoint.
SharePoint’s default tempauth capability is of particular concern. It generates signed URLs that permit file downloads without further authentication or IP restrictions. These links bypass Conditional Access and remain valid for extended periods, yet many organizations are unaware that this feature exists.
SharePoint generates enormous volumes of legitimate behavior as users download files, search content, and communicate. All that activity makes threat detection difficult because malicious actions can appear indistinguishable from normal use. This means a compromise can go unnoticed for an extended period.
AI services
Artificial intelligence platforms are acting as an accelerant to these problems because AI services are introduced rapidly, often outside traditional governance processes, and are even more explicit in promising fast, easy, automated, fully integrated implementations.
Most organizations have been found to leave standard access, encryption, and identity settings untouched during AI service deployments.
These are not advanced misconfigurations. They are basic defaults allowed to exist because they don’t call attention to themselves at the expense of a frictionless user experience.
AI tooling also introduces new identities, new APIs, and new data flows that security teams may not fully take stock of.
Moving beyond baseline security
Secure-by-default initiatives reduce only the most obvious security lapses. Basic checklists and frameworks allow cloud services to function, but don’t account for how organizations actually use them. They raise security to a level that is sufficient to get customers out without immediate issues but they do not eliminate the responsibility that comes with using cloud products safely and effectively.
Security teams need to view and treat identity systems, collaboration platforms, and integrated AI services as core infrastructure rather than set-and-forget layers of convenience. That set-and-forget is also imperative, as defaults assumed to be safe may behave in unexpected ways when used or circumvented creatively.
Overall cloud resilience depends on questioning what has been automatically enabled, understanding why, and then making calculated decisions about whether or not it is relevant, or even potentially hazardous, for an organization’s specific application and environment.
Sources:
Virtualization & Cloud Review, Reversec, Dark Reading, GreenLoop
About NetworkTigers
NetworkTigers is the leader in the secondary market for Grade A, seller-refurbished networking equipment. Founded in January 1996 as Andover Consulting Group, which built and re-architected data centers for Fortune 500 firms, NetworkTigers provides consulting and network equipment to global governmental agencies, Fortune 2000, and healthcare companies. www.networktigers.com.
