Microsoft Secure Default Exchange and Teams

Microsoft Strengthens API Security for Exchange and Teams with Admin Approval Requirement

As part of its ongoing efforts to strengthen cloud security, Microsoft is introducing a major policy update that will require administrator approval for all new third-party applications seeking access to Exchange and Teams data.

This change, part of Microsoft’s broader Secure Future Initiative, is scheduled to roll out between late October and late November 2025. The update falls under Microsoft’s “Secure by Default” approach, designed to tighten access controls and protect organizational data across Microsoft 365 environments.

What’s Changing and Why It Matters

The core of this update involves changes to the default consent policy managed by Microsoft. Moving forward, any new third-party app requesting access to Exchange or Teams content via APIs such as Microsoft Graph, Exchange Web Services, Exchange ActiveSync, POP3, or IMAP4 will now require explicit administrator approval before access is granted.

This policy does not impact existing apps that users have already authorized. However, if an app requests new permissions or a new user tries to authorize it, the administrator consent process will be triggered.

Organizations that have already implemented custom user consent policies will remain unaffected by this change.

A Consistent Security Approach Across Microsoft 365

This move aligns with previous Microsoft efforts to improve baseline security, including earlier changes to SharePoint and OneDrive, where legacy protocol access was blocked and admin consent was required for file-level third-party access.

By expanding this model to Exchange and Teams, Microsoft continues to harden its platform against potential abuse and unauthorized data access, without requiring customers to purchase additional licenses.

What IT Teams Should Do Now

To prepare for the rollout, Microsoft recommends several key actions for IT administrators:

  1. Review Existing Permissions
    Audit your current environment to identify third-party applications accessing mail, calendars, contacts, and Teams chat or meeting data.
  2. Enable the Admin Consent Workflow
    Set up the admin consent request workflow in Azure AD (Entra ID). Without this, users won’t have a way to request access to blocked apps.
  3. Create App Access Policies for Trusted Apps
    For critical third-party tools your organization relies on, preemptively create granular app access policies to avoid disruption.
  4. Communicate the Changes
    Inform IT teams, app owners, and security personnel about the upcoming policy shift. Update on-boarding documentation and internal guidelines accordingly.

This policy update underscores Microsoft’s commitment to improving tenant security by default, giving administrators greater control and visibility into third-party integrations. With rising threats targeting collaboration platforms and messaging systems, this is a timely and necessary evolution in Microsoft’s security posture.

red-hat-history-shadowman

Red Hat Confirms Major Security Breach Involving Internal GitLab Instance

Red Hat, widely recognized as the world’s leading provider of enterprise open-source solutions, has confirmed a significant cybersecurity incident involving unauthorized access to an internal GitLab server used by its Consulting team.

The breach, now under active investigation, follows claims by the hacker group Crimson Collective, who allege they exfiltrated approximately 570GB of compressed data from over 28,000 private repositories. If accurate, this would mark one of the most substantial source code leaks in recent memory.

Red Hat Consulting GitLab Environment Is The Target

According to Red Hat’s official disclosure, the breach targeted a GitLab environment used for collaboration within Red Hat Consulting, supporting engagements with select clients. An unauthorized third party was able to access and extract data from the server before detection.

In response, Red Hat initiated a full-scale investigation, cut off attacker access, isolated the compromised system, and alerted the relevant law enforcement agencies. The company has since rolled out additional security hardening measures.

What Was Exposed?

Initial reports suggest the stolen data includes a vast trove of sensitive technical assets, such as:

  • CI/CD secrets and pipeline configurations
  • VPN profiles and infrastructure blueprints
  • Ansible playbooks and OpenShift deployment guides
  • Container registry configurations and Vault integration secrets
  • SSH keys, API tokens, and database credentials

Security researchers examining the data found references to thousands of organizations, spanning multiple critical sectors. These include major financial institutions like Citi, JPMC, and HSBC, telecom giants such as Verizon and Telefonica, industrial leaders like Siemens and Bosch, and even U.S. government entities, including the U.S. Senate.

Potential Supply Chain Risks

The breach is being described as a supply chain threat, as many of the exposed repositories contain Infrastructure-as-Code templates, automation scripts, and configuration files that could be weaponized in secondary attacks.

Particular concern are:

  • Kubernetes deployment manifests
  • Container registry credentials
  • GitLab CI/CD runner configurations
  • Privileged deployment pipelines

These components often carry elevated access within enterprise environments, making them prime targets for lateral movement or persistent backdoor access.

Red Hat’s Response & Ongoing Investigation

Red Hat has emphasized that its main software supply chain and official distribution channels remain unaffected. The breach is not linked to the recent CVE-2025-10725 vulnerability involving OpenShift AI services.

While forensic analysis is still ongoing, Red Hat has committed to notifying any Consulting clients directly affected by the breach. The company continues to work with cybersecurity experts and authorities to fully understand the incident’s impact.