For years, security in enterprise technology worked on an opt-in model. You deployed the product, then you configured the protections. You applied the policies, enabled the logging, set the access controls, and tightened the defaults that shipped permissive out of necessity, or out of habit. The burden of getting to a secure state fell entirely on the organization using the product.
Secure by default changes that model fundamentally. It shifts the starting point. Under a secure by default approach, protections are active before the first user logs in.
MFA is required, not suggested. Legacy authentication protocols are blocked, not available. Logging is enabled, not optional. The secure configuration is not something you build toward, it is where you begin.
This distinction matters more now than it ever has. The most common causes of enterprise cloud breaches, misconfigured resources, overprivileged accounts, absent MFA, unmonitored identities, are not sophisticated failures. They are gaps that exist because the default posture was never secure to begin with, and no one got around to closing them.
“Many organizations don’t have the bandwidth to audit every default setting across every platform. Secure by default means the platform takes responsibility for the baseline, so your team can focus on what actually requires human judgment.” — Jorge Zelaya, CISO, Atmosera
That shift in responsibility, from the customer to the platform, is not just an operational convenience. It is a structural change in how risk is distributed across the technology ecosystem. And it is now being codified at the policy level by some of the most influential bodies in enterprise cybersecurity.
Secure by Design and Default: Understanding the Distinction
These two concepts are often used interchangeably. They are not the same thing, and the difference matters for how your organization applies each one.
CISA, alongside the FBI, NSA, and cybersecurity agencies from eight allied nations, published formal guidance on both principles. According to CISA’s Secure by Design framework, the two principles address different phases of the product and deployment lifecycle:
- Secure by design is an engineering discipline. It covers the decisions made during product development; what to build in, what attack surfaces to eliminate, what dependencies to introduce, before any code ships to a customer.
- Secure by default is an operational reality. It describes the state a product or environment is in when it arrives. MFA enforced. Legacy protocols blocked. Logging enabled. No extra steps required to reach a secure baseline. You start there.
The relationship between the two is sequential. Secure by design determines what controls are available. Secure by default determines whether those controls are active when you first open the door.
Both matter. An organization running a well-designed product with poor defaults is still exposed. One enforcing secure defaults on a poorly architected product is improving its posture but may still carry underlying risk. The strongest security posture comes when both work together, intentional architecture and protected starting points.
For enterprise teams operating in Azure and Microsoft 365, this distinction has direct operational significance. Microsoft’s choices on both dimensions shape what you inherit when a tenant is created, and what your team is responsible for building from there.
| Learn how you can further safeguard your enterprise’s infrastructure, data, and more: |
Microsoft Secure by Default: How the Secure Future Initiative Is Raising the Standard
Microsoft’s approach to secure by default is not simply a product feature. It is a governing philosophy embedded into the company’s largest and most ambitious security program in its history.
Launched in November 2023, the Microsoft Secure Future Initiative (SFI) is organized around three principles: secure by design, secure by default, and secure operations. Microsoft describes secure by default as the principle that “security protections are enabled and enforced by default, require no extra effort, and are not optional.” The SFI has mobilized the equivalent of 34,000 full-time engineers to execute against that commitment.
The practical results of this commitment are visible in how Microsoft has restructured the default behavior of its most widely used enterprise platforms.
Microsoft Entra ID Security Defaults
Security Defaults are now enabled for every new Microsoft Entra ID tenant. According to Microsoft’s official Entra documentation, these defaults enforce MFA registration for all users on first login, block legacy authentication protocols that cannot support modern MFA methods, and require MFA for all administrator actions. The 14-day grace period that previously allowed users to defer MFA registration has been removed. MFA must be configured before any access is granted.
The reason for that requirement is straightforward: Microsoft’s own data shows that MFA blocks over 99.2% of identity-based attacks. An environment that does not enforce MFA by default carries a known, quantified, and preventable exposure.
Microsoft 365 Secure by Default: Mandatory MFA for Admin Centers
Microsoft 365 secure by default enforcement extended further in early 2025. Starting February 3rd, 2025, Microsoft began requiring MFA for all accounts accessing the Microsoft 365 admin center. This requirement rolled out in phases across tenants and was followed in September 2025 by mandatory MFA enforcement across Azure CLI, Azure PowerShell, Infrastructure as Code tools, and REST API CRUD operations.
The direction is consistent and deliberate. Across Azure, Microsoft 365, and Entra ID, the default posture is being hardened. Administrators who have been managing these environments with configurations that predate the SFI will find that the expected baseline has moved, and that environments not yet aligned to these defaults carry more exposure than they may realize.
SFI’s Broader Secure by Default Commitments
Beyond identity, the April 2025 SFI Progress Report documented 11 new security innovations across Azure, Microsoft 365, Windows, and Microsoft Security, all aligned to improving default security posture.
Signing keys for Entra ID and Microsoft Account have been moved to hardware security modules with automatic rotation. Conditional Access policies are being expanded. Logging and detection capabilities are being built into platform layers that previously required additional configuration.
These are not optional upgrades. They are platform-level changes that affect every organization operating in the Microsoft ecosystem. Understanding what Microsoft now considers the default, and ensuring your environment reflects it, is a core responsibility for any enterprise security team.
Assess Your Azure Security Baseline
Atmosera assesses your current Azure posture against a secure by default architecture—identity governance, configuration state, network controls, and monitoring coverage included.
From Principles to Practices: What a Secure by Default Framework Looks Like in Operation
Knowing the principles is one thing. Operationalizing a secure by default framework across a live enterprise environment is another.
The organizations that execute this well share a common pattern. They treat secure by default not as a project with a completion date, but as an operational discipline with continuous measurement. Here is what that looks like in practice.
Baseline Definition and Documentation
A secure by default framework begins with a documented baseline; a defined, approved configuration state for every category of resource in your environment. That baseline answers the question: what does ‘secure by default’ mean, specifically, in this environment, for this resource type?
For an Azure tenant, that baseline includes specific Entra ID settings, defined Conditional Access policies, required Defender for Cloud configurations, approved network security group rules, and data classification and encryption requirements.
It is not a generic industry standard. It is your organization’s specific answer, informed by standards like NIST, CIS, and Microsoft’s own security recommendations.
Provisioning Aligned to the Baseline
Every resource deployed into your environment should be provisioned from infrastructure-as-code templates that embed the baseline configuration. This removes the dependency on individual engineers making correct security choices under time pressure and replaces it with a repeatable, auditable process that produces consistent results.
Secure by default practices in provisioning mean that a developer cannot accidentally deploy an overly permissive storage account, because the template does not permit it. The guardrails are in the process, not in the person.
Continuous Monitoring and Drift Detection
The baseline is only valuable if deviations from it are detected and remediated. A mature secure by default framework includes continuous monitoring that compares actual configuration state against the defined baseline in real time, not at the next quarterly review.
This monitoring should cover identity and access, resource configuration, network controls, and security logging.
Alerts for configuration drift should be routed into the same response workflow as security incidents, because configuration drift is a security risk, not an administrative inconvenience.
Exception Management with Full Visibility
There will be legitimate reasons to deviate from secure defaults. A workload may require a legacy protocol for a specific integration. A resource may need broader access than the baseline permits for a defined period of time. These exceptions are acceptable if they are documented, approved, time-limited, and visible.
A secure by default framework makes exceptions explicit. The cost of deviation from the baseline is visible, and that visibility is what keeps exceptions from becoming the norm.
Training Aligned to the Framework
The human layer matters. A secure by default framework is only as strong as the teams that operate within it. Security training should be specific to the configurations and tools your organization uses, not generic awareness content.
Engineers should understand why the baseline is configured as it is, what the risks are of deviation, and how to raise and resolve configuration issues through established channels.
The table below illustrates how a secure by default framework changes the operational posture across common control areas:
| Control Area | Traditional Approach | Secure by Default Approach |
| MFA enforcement | Optional or off by default | Required on first login, no grace period |
| Legacy authentication | Allowed unless explicitly blocked | Blocked by default across all tenants |
| Admin access controls | Configured manually per environment | Privileged Identity Management enforced |
| Token lifetime | Extended or unmanaged | Short-lived, hardware-protected, auto-rotated |
| Security logging | Opt-in or requires additional licensing | Enabled by default with baseline retention |
| Audit & compliance | Periodic and manual | Continuous monitoring integrated into workflow |
How Atmosera Helps You Take the Secure by Default Approach
The gap between knowing what a secure by default posture should look like and achieving it across a live enterprise environment is where most organizations struggle.
The principles are not complex. The execution requires deep, specific knowledge of the platforms you operate on and the operational capacity to monitor, maintain, and respond to a continuously evolving environment. For most enterprises, that is not a gap a single tool or a single configuration change can close.
Atmosera works with mid-market and large enterprises operating on Microsoft Azure to:
- Assess current identity, configuration, and network posture against a secure by default baseline
- Align Microsoft Entra ID, Conditional Access, and Defender for Cloud to SFI‐aligned security defaults
- Implement continuous posture management so configuration drift is detected in real time, not at the next audit
- Build provisioning frameworks, such as infrastructure-as-code templates and Azure Policy definitions, that embed secure defaults at the point of deployment
- Provide 24/7/52 US-based monitoring and incident response so that security is maintained operationally, not just architecturally.
With 27 years in business, Azure Expert MSP designation, eight Microsoft Gold Partnerships, and 99.9% uptime across managed environments, Atmosera brings the depth of experience that makes the difference between a security posture that looks correct on paper and one that holds up in practice.
Secure by default is not a configuration checkbox. It is a standard that your environment either meets continuously or does not. The organizations that get there are the ones that build it as an operational practice, not a one-time project.
Ready to align your Azure environment to a secure by default standard?
Atmosera provides the assessment, the architecture, and the ongoing management that a genuine secure by default approach requires. Let’s start with a clear picture of where you stand today.