This week we will review Microsoft's September '24 progress report on their Secure Future Initiative.

This document is oriented towards cybersecurity practitioners, rather than tech sales reps or investors in the industry.

The reason why this is relevant to us is because it will help illustrate a very important point about what the actual concerns and needs of cybersecurity teams are versus the "my software will save you" point of view that vendors often focus on. I'll also introduce for the first time a new intro to these newsletters, focusing on the key takeaway for our two target audiences.

The key takeaway

For tech sales: The "Secure Future Initiative" is a great example of both what we would consider a compelling event, but also a complex challenge to tackle from a sales perspective. The key decisions being taken are often process-related, rather than technology-driven. Trying to shoe-in a vendor pitch here (particularly keeping in mind the large investment by Microsoft in internal solutions) is pointless - a successful sales cycle would be driven by an advisory-style sale, focused on showing gaps in their proposed approach to solving some of their challenges as outlined in this document.

For investors: Microsoft's biggest long-term risk remains the very negative market perception of their security culture. Satya has clearly gained momentum to drive internal change in the last 12 months, particularly after several very public and reputation-damaging events. While the "Secure Future Initiative" is showcasing an impressive momentum in this internal change, there are upcoming "risky" events such as the rollout of Windows 24H2 and its controversial Recall feature. This will be one of the first big events that should demonstrate whether their structurally different approach by the company on security is now translating into customer-facing products. I see significant security breaches related to Azure AI Service as a huge operational and reputational risk for the company. Preventing and minimizing those risks are mission-critical to their growth strategy.

Let’s talk cybersecurity initiatives

In November 2023, Microsoft announced the Secure Future Initiative (SFI) to address the increasing scale, speed, and sophistication of cyberattacks. Launched as a multi-year endeavor, SFI evolves how Microsoft designs, builds, tests, and operates products and services to achieve the highest possible standards for security.
In May 2024, CEO Satya Nadella made security the company’s top priority, underscoring the importance of SFI as a comprehensive, cross-company effort that involves every employee in driving progress towards greater security and resiliency.
Our engineering teams quickly dedicated the equivalent of 34,000 full-time engineers to address the highest priority security tasks—the largest cybersecurity engineering project in history. We have also made significant improvements in governance and culture, such as integrating security into performance reviews and introducing the Security Skilling Academy.

Now one of the first things that we notice here is that they are not talking about “our CISO has budgeted an additional 25M to spend on qualified vendors”. This is an outline focused on CULTURE and GOVERNANCE.

Culture
• Significant investment: Dedicating the equivalent of 34,000 full-time engineers, SFI is the largest cybersecurity engineering project in history.
• Security as #1 priority: Security added as a core priority for all employees, measured against all performance reviews. Microsoft’s senior leadership team’s compensation is now tied to security performance.
• Security Skilling Academy: Launched in July, this academy offers curated training for all employees, reinforcing the importance of security in daily operations.
Governance
• The Microsoft senior leadership team reviews SFI progress weekly and updates are provided to the Microsoft Board of Directors quarterly.
• Introduction of Cybersecurity Governance Council and Deputy Chief Information Security Officers (Deputy CISOs) who are aligned with foundational security functions and all engineering divisions to help ensure comprehensive and cohesive security governance.

This is what operating at scale and driving cultural change means. All employees are expected to be involved, and have knowledge of the company's cybersecurity policies. Their pay will depend on their ability to execute against them.

Now, if we dig a bit deeper into the technical/engineering changes and try to assess whether these led to some software acquisitions:

Protect identities and secrets:
We completed updates to Microsoft Entra ID and Microsoft Account (MSA) for our public and US government clouds to generate, store, and automatically rotate access token signing keys using the Azure Managed Hardware Security Module (HSM) service. We have continued to drive broad adoption of our standard identity SDKs which provide consistent validation of security tokens.
This standardized validation now covers more than 73% of tokens issued by Microsoft Entra ID for Microsoft owned applications. We have extended standardized security token logging in our standard identity SDKs to support threat hunting and detections and enabled those in several critical services ahead of broad adoption. We completed enforcement of the use of phishing resistant credentials in our production environments and implemented video-based user verification for 95% of Microsoft internal users in our productivity environments to eliminate password sharing during setup/recovery.

Updates to internal systems and policy changes = no software bought.

Protect tenants and isolate production systems:
We completed a full iteration of app lifecycle management for all of our production and productivity tenants, eliminating 730,000 unused apps. We eliminated 5.75 million inactive tenants, drastically reducing the potential attack surface.
We implemented a new system to streamline the creation of testing and experimentation tenants with secure defaults and strict lifetime management enforced. We have deployed over 15,000 new production-ready locked-down devices in the last three months.

Mostly lifecycle management and configuration changes; one mention of an implemented system = likely internal product rather than new software bought.

Protect networks:
Over 99% of physical assets on the production network are recorded in a central inventory system, which enriches asset inventory with ownership and firmware compliance tracking. Virtual networks with backend connectivity are isolated from the Microsoft corporate network and subject to complete security reviews to reduce lateral movement. To help customers secure their own deployments, we have expanded platform capabilities such as Admin Rules to ease the network isolation of Platform as a Service (PaaS) resources such as Storage, SQL, Cosmos DB, and Key Vault.

Configuration changes and policy updates; upgrades to internal Azure services = no software bought.

Protect engineering systems:
85% of our production build pipelines for the commercial cloud are now using centrally governed pipeline templates, making deployments more consistent, efficient, and trustworthy. We have slimmed down the lifespan of Personal Access Tokens to seven days, disabled SSH access for all Microsoft internal engineering repos, and significantly reduced the number for elevated roles with access to engineering systems. We also implemented proof of presence checks for critical chokepoints in our software development code flow.

Optimisations of DevOps processes, changes to token policies; proof of presence checks is probably just leveraging the Windows implementation as a mandatory part of the workflow = no software bought.

Monitor and detect threats:
We have made significant progress enforcing that all Microsoft production infrastructure and services adopt standard libraries for security audit logs, to ensure relevant telemetry is emitted, and retain logs for a minimum of two years. For instance, we have established central management and a two year retention period for identity infrastructure security audit logs, encompassing all security audit events throughout the lifecycle of current signing keys. Similarly, over 99% of network devices are now enabled with centralized security log collection and retention.

Updates to their security audit logs and changes to how they centrally managed the logs. The increased retention period and higher scope of devices with ingested logs would imply an expansion of the workloads, however these are probably handled by Azure Monitor and Sentinel deployment expansions = no software bought.

Accelerate response and remediation:
We updated processes across Microsoft to improve Time to Mitigate for critical cloud vulnerabilities. We began publishing critical cloud vulnerabilities as common vulnerability and exposures (CVEs), even if no customer action is required, to improve transparency. We established the Customer Security Management Office (CSMO) to improve public messaging and customer engagement for security incidents.

Process and policy changes = no software bought.

Now a logical question following this might be - did they spend any money at all? Well, they did, but to hire more talent:

Each Deputy CISO represents and is accountable for a security domain—an engineering division into which they report, or a foundational security function reporting to the CISO.
The Cybersecurity Governance Council collaborates with SFI engineering leadership to define and prioritize SFI work as well as set future direction. The council is accountable for the implementation of regulatory requirements, ongoing compliance, and determining the security architecture necessary to achieve our goals. The council reports on cyber risk and compliance to the CISO, who in turn reports this information to the Microsoft senior leadership team and to the Microsoft Board of Directors.

Now if we try to analyse this from a different perspective - maybe they didn’t make software investments now, but is it potentially a structural part of achieving the outcome?

It might be obvious by now, but this initiative seems to be focused on policies and practices, rather than “we need to get an external software vendor to help us fix our mess”. Let’s see how these translate into practical actions:

Principles in practice
All product teams apply these principles by adopting the Microsoft Security Development Lifecycle (SDL), a practical security approach that is risk-driven and agnostic to development methodology or technology. It describes essential practices and specific requirements for all stages of a device, software, or service lifecycle to reduce the frequency and severity of vulnerabilities.
Examples of required processes
• Perform secure design review and threat modeling.
• Conduct usability testing to encourage secure configurations.
• Perform security testing to assess system security requirements.
• Incorporate threat intelligence feeds into security operations.
• Follow a well-developed and regularly tested incident response plan.
Examples of resulting product goals
• Encourage integrated authentication methods and use of Hardware Security Modules (HSM).
• Automate the application of best practices by enforcing automatic updates and conditional access.
• Provide mechanisms that help customers build their security awareness, adopt good security habits, and guard against social engineering and other deceptive attacks.
• Incorporate security logs and the ability to monitor activity into every product.
• Clearly and simply explain security settings and communicate risks of deviating from secure defaults.

While all of these are clearly very important steps, in practice what they translate into is a lot of focus to improving Microsoft’s internal development practices, methodologies and product design goals. There are likely multiple tools used to drive these in the backend, except that many of them will be homegrown (Azure DevOps for example).

To summarise, there is only one section where Microsoft might’ve invested further into and that is related to the monitoring part. In their detailed overview on that topic, they also present what is essentially one of the most high growth parts of cloud infrastructure software - the security analytics part of the stack:

Monitor and detect threats
The monitor and detect threats pillar focuses on ensuring that all assets within Microsoft production infrastructure and services are emitting security logs in a standardized format that are accessible from a centralized data system for both effective threat hunting/investigation and monitoring purposes. This pillar also emphasizes the development of robust detection capabilities and processes to rapidly identify and respond to any anomalous access, behavior, and configuration.
Key learning
Recent attacks and internal studies have reinforced the importance of a comprehensive—and up to date—asset inventory for effective investigation and monitoring. Each asset must emit standardized logs through centrally managed agents to ensure proper telemetry collection and retention. Easy authorized access to security logs for both internal teams and customers is crucial for efficient forensics. Logs must be available in a centralized data system for threat hunters and investigation teams. Providing timely security logs to customers enables their own investigations and detections. To stay ahead of threats, we must build detections using advanced analytics, machine learning, and threat intelligence to identify malicious activity.

Conclusion

Cybersecurity is an extremely complex problem to solve. Practitioners need to have a deep understanding of multiple disciplines and juggle many hats in order to achieve improved outcomes (because there is no such thing as a perfect outcome in this industry).

Any tech sales rep who works for a "playbook" company would have been told to chase after THE CYBERSECURITY TRANSFORMATION playing out as an obvious compelling event.

Based on this deep dive, I hope it's become more clear that the deep structural challenges at Microsoft from a security perspective have little to do with technology choices. This is reflected in how little example of any software acquisition activity there are in this document.

That doesn't mean that there aren't opportunities for the right company and the right vision - but it needs to be strongly aligned with what the actual customer need is rather than what the vendor wishes this transformational project could be.

Now, the investor view here is a little different. The efficiency demonstrated by Microsoft in driving effective, rather than performative, changes in their security strategy is impressive. I think that there is a genuine attempt at addressing long-term structural issues and there is momentum across multiple key stakeholders to drive this change.

The fact that individuals are now being benchmarked and compensated/punished based on their execution of this strategy shows a deeper understanding of the fact that these problems will not be solved by technology, but by re-aligning incentives.

The LinkedIn post above is interesting in the context that Microsoft already had an edge to its competitors from an execution perspective, even with its significant black-eye around security. Meaningful progress on this front would put the company in a leading position to win new workloads over the next few years.

Where I disagree with the opinion above is in the idea that the views of cybersecurity practitioners and leaders will not impact future investment towards Microsoft - the reality on the ground is a little more shaky. With Azure AI Service being critical to the recent accelerated growth in the company, a high-profile breach directly connected to the structural issues at Microsoft would likely lead to a significant reduction in spend, as customers opting into the "safe space" of AWS. It's essential to remember that as models themselves do not create a moat, picking Bedrock over Azure AI Service is an ecosystem preference rather than a huge technical decision.

The Tech Sales Newsletter #62: The cybersecurity culture transformation at Microsoft

The key takeaway

Let’s talk cybersecurity initiatives

Conclusion

The Tech Sales Newsletter #63: Where are CIOs going to spend their money in 2025?

The Tech Sales Newsletter #61: Tech sales culture starts with hiring