Microsoft flips security script: ‘In scope by default’ makes all vulnerabilities fair game for bug bounties

Tags:

Today’s AI-enabled attackers are agnostic: They’re not limiting themselves to specific companies, products, or services — they’re going where the vulnerabilities are. To meet them on this ground, Microsoft is pivoting its cybersecurity strategy to what it calls ‘In Scope by Default.’

Now, any “critical vulnerability” with a “demonstrable impact” on Microsoft’s online services is eligible for a bounty award. This applies to code owned and managed by Microsoft, as well as to anything delivered by a third party or via open-source.

Threat actors “don’t care who owns the code they try to exploit,” Tom Gallagher, VP of engineering at the Microsoft Security Response Center, wrote in a blog post announcing the new security policy. “The same approach should apply to the security community who continue to partner with us to provide critical insights that help protect our customers.”

Goal to ‘incentivize research’

‘In Scope by Default’ was announced at Black Hat Europe on Friday, with Gallagher saying that Microsoft “will do whatever it takes” to remediate surfaced issues.

This strategic shift comes as attackers continuously up their game, aided by AI tools. Microsoft was recently impacted by a zero-day vulnerability in SharePoint that trickled down to businesses and government agencies alike, and in October, the company’s own security update triggered a range of failures. And just today, to plug the gap until Microsoft can develop its own fix, free unofficial patches were made available by a third party for a newly-discovered Windows zero-day vulnerability that gives attackers the ability to crash the Remote Access Connection Manager (RasMan) service.

Microsoft has employed a range of tactics to combat these threats. Gallagher pointed out that, in 2024, the company awarded more than $17 million through its bug bounty program and live hacking events, and its strategy pivot will expand award eligibility. Rather than only being offered for bugs in defined scopes, issues with all online services will be included by default, and as soon as the services are released.

“Our goal is to incentivize research on the highest risk areas, especially the areas that threat actors are most likely to exploit,” said Gallagher.

Eligibility will now include:

Microsoft-owned domains and cloud services. Security researchers without Microsoft insider perspective will be encouraged to target its infrastructures via agreed upon rules of engagement.

Third-party code, including open source. In cases where no bug bounty exists in this area, Microsoft will now offer one. Identifying vulnerabilities in third-party code can help raise the bar for “everyone who relies on this code,” Gallagher noted.

This shift is “quite significant,” particularly for a company of Microsoft’s size, noted Erik Avakian, technical counselor at Info-Tech Research Group. The new default inclusion policy is backed by process and governance, and is being applied across the tech giant’s “massive, heterogeneous ecosystem.”

“Microsoft is explicitly pulling third-party and open-source dependencies into scope when they impact Microsoft services, which reflects how real attacks actually traverse shared infrastructure rather than clean product boundaries,” said Avakian.

Researchers are welcome to submit their findings for assessment and for coordinated disclosure, the practice of privately reporting vulnerabilities to vendors so that they can diagnose and fix issues before they are announced publicly.

Microsoft and its partners follow the Rules of Engagement for Responsible Security Research, Gallagher noted, which encourages a variety of red teaming activities, such as performing vulnerability assessments on Azure virtual machines (VMs), testing surge capacity, attempting to break out of system boundaries and shared service containers, testing security monitoring and detection systems, and evaluating conditional access.

However, these rules of engagement prohibit red teamers from using or accessing credentials that aren’t their own, launching phishing attacks against Microsoft employees, performing denial-of-service testing or other testing that generates excessive traffic, or interacting with storage accounts not included in a user’s own subscription.

Pros and cons to the approach

This widening of scope isn’t necessarily new, noted Info-Tech’s Avakian, though cloud service providers (CSPs), financial institutions, and SaaS companies publish narrower scope language and handle many cases through back-channel negotiation. But much of this still relies heavily on researcher goodwill and internal judgment calls.

Microsoft’s wider scope is a bit different, and could result in fewer gray-area arguments and the “is this in scope?” back-and-forth questioning that can expend time and create friction with researchers, said Avakian. It also provides better signaling: If people don’t fear disqualification, they’re more likely to submit early-stage findings. This is great for defenders and can foster stronger trust in the research community.

“It helps send a clear message: ‘We want to hear about problems,’ and internally, it forces ownership,” said Avakian. “Once something’s in scope by default, it helps to force maturity.”

However, this could get difficult when it comes to volume, potentially leading to more low-quality reports and speculative or “nebulous” findings, he said. Engineering teams can burn out quickly if everything is treated as urgent, or if severity isn’t well-communicated.

“But this model can work if severity discipline is rock solid,” said Avakian.

However, attackers could benefit indirectly if defender teams become overloaded, where potential noise could drown out real signals, and fix velocity could slow due to triage backlogs. “In other words, operational drag could very well become the attacker’s friend,” said Avakian.

Researchers, for their part, might go down unconventional attack path rabbit holes, and less ethical hackers may spray “low-effort findings” at scale and use ambiguity to pressure for bounty money or even publicly frame rejections as Microsoft ignoring security, he noted.

Ultimately, “scope is really a governance decision,” said Avakian, pointing out that enterprises fall behind when vulnerability programs are still written primarily to reduce payouts, minimize exposure, and protect brand optics.

“Microsoft is signaling that operational clarity beats defensive ambiguity,” said Avakian. However, “in scope by default” only works with maturity behind it.

“If you don’t already have strong governance, triage processes, consistent severity models, and engineering accountability, it becomes problematic,” he said. “Automation, enrichment, and experienced human judgment matter more than ever here, and Microsoft appears to be clearly investing in that long game.”

Categories

No Responses

Leave a Reply

Your email address will not be published. Required fields are marked *