Test tenants are production when their apps can reach production

The week

On January 19, 2024, Microsoft disclosed in a filing with the U.S. Securities and Exchange Commission that a Russian state actor it tracks as Midnight Blizzard had accessed a very small percentage of its corporate email accounts. Those accounts included members of senior leadership and staff in cybersecurity and legal: the people whose inboxes hold some of a company’s most sensitive conversations.

The filing said Microsoft had detected the attack on January 12. It said the incident had not, as of that date, had a material impact on the company’s operations, and that Microsoft had not yet determined whether it was reasonably likely to. The disclosure came under Item 1.05 of Form 8-K, the section for material cybersecurity incidents that the SEC’s new disclosure rules had added the previous month. It was among the first high-profile filings under that item, and it showed how companies would use it before materiality was settled.

The actor was not new. Microsoft also tracks it as NOBELIUM, and others call it APT29 or Cozy Bear. The U.S. and UK governments attribute it to Russia’s Foreign Intelligence Service, the SVR. Microsoft described it as focused mainly on governments, diplomatic bodies, non-governmental organizations and IT service providers in the United States and Europe. It was the same group behind the SolarWinds supply-chain compromise disclosed at the end of 2020.

On January 25 Microsoft published more detail about how it happened, and the method was strikingly ordinary. The actor had used a password spray, which means trying a handful of common passwords against many accounts in the hope that one fits. Microsoft said the actor used a low number of attempts against a limited set of accounts, to avoid detection and lockouts. That attack compromised a legacy, non-production test tenant account that lacked multifactor authentication. A “tenant” is an organization’s own private space in a cloud service such as Microsoft 365. A test tenant is a separate one set up for experiments. Multifactor authentication, or MFA, is the second check, such as a code on your phone, that stops a stolen password from being enough on its own.

The traffic was routed through residential proxy networks, so the login attempts came from internet addresses that ordinary households also use. Microsoft noted that this made blocklists of known bad addresses ineffective as a defense or as a hunting tool.

From that foothold, the actor used a legacy test OAuth application with elevated access to Microsoft’s corporate environment. OAuth is the standard technology that lets one piece of software act on your behalf in another, the same mechanism behind “Sign in with Google” or an app asking to read your calendar. An OAuth application can be granted permissions, and this old test app had been granted powerful ones in the real corporate environment. The attacker used it to create further applications and created a new user account to consent to them in the corporate environment. The legacy app then granted the new apps the Exchange Online “full_access_as_app” role, which allows access to mailboxes in the cloud email service Microsoft runs for itself and its customers.

Microsoft’s post was written for defenders. It listed the audit events and alerts that would reveal similar activity, and recommended auditing every application and service principal for unknown, unused or over-privileged access. It said the same actor was targeting other organizations, which Microsoft had begun to notify.

Microsoft was not alone. On January 24, Hewlett Packard Enterprise disclosed in its own filing that the same actor had accessed its cloud-based email environment. HPE said it had been notified on December 12, 2023. The actor had taken data, beginning in May 2023, from a small percentage of mailboxes belonging to staff in cybersecurity, go-to-market, business segments and other functions. HPE said the activity was likely related to an earlier incident, of which it was notified in June 2023, involving a limited number of SharePoint files.

No exotic hacking tool was needed. A forgotten account, a missing second factor and an old app with too much power were enough to put a foreign intelligence service inside the inboxes of a technology giant’s leadership.

Most organizations classify identities by the environment they live in. An identity is anything that can log in and act inside a system: a person’s account, but also a piece of software, a script or a device. Production accounts, the ones that touch real customers and real data, get strong authentication, monitoring and access reviews. Test and development accounts get less, on the reasoning that they hold no real data.

Microsoft’s account of the intrusion shows why that classification fails. The test account held nothing of value. What mattered was what it could reach.

A better test asks three questions of any identity, whatever its label: who can log in to it, what it can reach, and who would notice it acting. The answers are independent. An identity can be hard to log in to but have vast reach, or easy to reach but closely watched. Risk sits where all three answers are bad, as they were here.

The three questions also map to three different owners. Exposure is usually the identity team’s problem. Reach is shared between identity, application owners and whoever approves vendor integrations. Detection belongs to the security operations center. An organization can be strong on one and weak on the others without any single team seeing the whole picture. The sections below explain the building blocks and take each question in turn. They then follow how a forgotten app comes to exist, weigh what is at stake, and end with how to get the answers on demand.

Tenants, identities and apps

Microsoft 365 is the cloud suite that provides email, documents, Teams and much more to a great many companies, hospitals and government agencies. Behind it is Entra ID, Microsoft’s identity service, formerly known as Azure Active Directory. Entra ID is the gatekeeper: it decides who and what can sign in, and what each is allowed to do once inside.

Each customer organization has at least one tenant, its own walled-off space in that cloud. Large organizations often have many. Some are created for pilots, some for testing new features, some arrive through acquisitions. Each tenant has its own settings, its own rules and its own administrators.

Inside a tenant there are two broad kinds of identity. Human identities belong to people. Non-human identities belong to software: applications, automated scripts and integrations that move data between systems. In Microsoft’s world an application is defined by an “app registration” and acts through a “service principal,” the app’s working identity in a given tenant. In a large organization there can be a great many of these non-human identities, and they are much less visible than people.

Apps get their powers through permissions. Some permissions let an app act only on behalf of a signed-in user, with that user’s rights. Others, called application permissions, let the app act entirely on its own, across the whole tenant, at any hour. A permission such as the ability to read every mailbox is, in effect, a master key. Whoever controls the app controls the key.

One definition, many footholds

The split between app registration and service principal matters more than it sounds. The registration lives in one “home” tenant and defines the app: its name, its credentials and the permissions it asks for. A service principal is created in every tenant where the app is used. An app registered in a test tenant can therefore have a service principal, with real permissions, in the production tenant. The production tenant’s administrators see the service principal. The credentials that control it may be managed elsewhere.

Apps prove who they are with secrets or certificates. A secret is a long password held by a machine, and a certificate is a digital credential. Anyone who can add a new secret or certificate to an app can then sign in as that app. That right belongs to the app’s owners and to administrators with certain directory roles. Control of an app is therefore a question of who can add credentials to it, and that list is rarely reviewed.

Consent is how permissions get attached. A user can consent to an app acting on their behalf, within limits the tenant sets. An administrator can grant consent for the whole organization, including application permissions that need no user at all. Once granted, consent persists until someone removes it. A pilot that ended years ago can still hold a grant made on its first day.

Who can log in: exposure

The first foothold came from a password spray, the oldest identity attack there is. The attacker tries a few common passwords across many accounts, slowly, often from residential proxy addresses so that the traffic looks ordinary. A residential proxy routes the attacker’s traffic through ordinary home internet connections, so the login attempts appear to come from a household rather than a known hacking server. The technique works only against accounts that accept a password alone from the internet.

Spraying is designed to slip under lockout rules. Lockout counts failed attempts against one account. A spray makes one or two attempts per account, spread across hours or days, so no single account crosses its limit. Detection has to look across accounts, for many failures sharing a pattern, and that pattern is harder to see when each attempt comes from a different home address.

In a large Microsoft 365 or Entra ID estate, those accounts cluster in predictable places. Test tenants are created for a pilot and never get the conditional access policies of the main tenant. Conditional access is the rulebook that says, for example, “require MFA for everyone” or “block sign-ins from outside our networks.” Tenants inherited through acquisitions keep their old settings. Inside the main tenant, accounts are excluded from MFA because a script or a legacy device could not cope. Each exclusion made sense when it was granted. Few were ever revisited.

Where the password-only accounts hide

The exclusions follow a familiar pattern by sector. Health systems often exempt shared clinical workstation accounts, or accounts used by medical devices and interface engines, because a second factor would slow care or break an integration. Banks and credit unions tend to carry service accounts created years ago for core banking connectors, scanners and reporting jobs. Agencies often have accounts left over from migrations, and accounts shared by contractors. In each case the account is a user account doing a machine’s job.

Microsoft’s own guidance is to move such accounts to proper workload identities, which authenticate with certificates or managed credentials and cannot be password-sprayed. That migration takes engineering effort, because scripts and integrations must be rewritten. It also removes the reason for the exclusion, which is the only durable fix.

The controls are concrete. Keep a register of every tenant the organization owns, with an owner and a baseline. Apply the same sign-in policy baseline to test tenants as to production, or block interactive sign-in to them from outside corporate networks. Treat every MFA exclusion as a dated exception, approved like a firewall rule and reviewed on the same cycle.

The regulatory floor is rising

Different organizations face different rules here, and they are converging. New York’s financial services regulator amended its cybersecurity regulation in November 2023. Covered banks, insurers and other licensees must require MFA for any individual accessing any of their information systems, and maintain an asset inventory, by November 2025. Federal agencies have worked under a 2022 White House memorandum that pushes phishing-resistant MFA for staff. For health systems, the HIPAA Security Rule has long required access controls and audit controls, and a rule change proposed at the start of 2025 would add explicit MFA and asset inventory requirements. No rule among them says “test tenant.” All of them reach any system that can touch regulated data, which is the point of the reach question.

Measuring this is straightforward. Count the accounts, in every tenant, that can complete an interactive sign-in from the internet with a password alone. The target is zero, with a short, named list of approved exceptions. Report that number to the CISO, the chief information security officer, monthly, broken down by tenant. The figure tends to surprise. Teams that manage the main tenant well often have no view of the others, because test tenants are created by developers and project teams outside the identity team’s change process. Bringing tenant creation itself under a request and approval workflow stops the problem from regrowing.

There is a trade-off with developer productivity. Blocking all internet sign-in to test tenants frustrates remote engineers and pushes them to create unsanctioned ones. A middle course is to require a managed, compliant device for test tenant sign-in, which defeats remote spraying without forcing developers onto the corporate network.

What it can reach: privilege across boundaries

The decisive step was the OAuth application. A legacy test app had been granted elevated access to Microsoft’s corporate tenant. That single grant turned a compromised test account into a route into production. Using it, the actor created new applications and gave them a role that allowed access to mailboxes across Exchange Online. No user had to approve anything during the attack. The permission was already in place.

The heart of the story is this. The boundary between “test” and “production” was supposed to be a wall. The app’s permission was a door in that wall, and nobody remembered it was there.

Application identities are easy to overlook because they do not behave like users. They authenticate with secrets or certificates, not passwords. They do not trigger MFA prompts. Many hold tenant-wide application permissions, which work without any user being signed in. A multitenant app registered in one tenant and consented in another creates a trust path that neither tenant’s user review will show. Consent is the act of approving an app’s request for permissions; once given, it persists until someone takes it away.

The inventory that matters is therefore one of permissions. For every app registration and service principal, the organization needs to know what permissions it holds, in which tenants, who consented and when, who owns it, and when it last did anything. In practice, the highest-risk entries are a small set: apps with permission to read all mail, write to the directory, or grant roles to other apps. Those deserve the scrutiny given to domain administrators, the most powerful human accounts in a traditional corporate network.

Ranking permissions by blast radius

Not every permission deserves the same attention, and a review that treats them equally will drown. A simple ranking helps. At the top are permissions that let an app grant permissions or roles, to itself or to others. In Microsoft Graph these include the rights to manage app role assignments, to manage directory roles and to manage all applications. An app holding one of these can escalate to anything, which is what the legacy test app did when it handed the mailbox role to new apps.

Next come permissions that read or change large bodies of data across the tenant: all mail, all files, all users. Below them are permissions scoped to specific mailboxes, sites or groups, and delegated permissions that act only with a signed-in user’s rights. The top tier should be close to empty and reviewed monthly. The second tier should be scoped wherever the product allows it. The rest can follow the normal quarterly cycle.

Other doors between tenants

Multitenant apps are one cross-boundary path among several. Guest accounts let users from one tenant work in another. Cross-tenant synchronization copies users between tenants in the same group. Partner administration relationships let a reseller or managed service provider administer a customer tenant. Each is legitimate, and each creates reach that a review of a single tenant will miss. A full map of reach covers all of them, starting with any path that ends in administrative rights or mailbox access in production.

Scoping instead of removing

Health systems and agencies face a long tail of such apps, from EHR and case management integrations to mail-processing and analytics connectors. An EHR, or electronic health record, is the system that holds patient charts; a case management system tracks the files of a benefits office or social services department. Each integration may need real permissions to do useful work. The aim is to know, scope and own them, not to remove them.

Scoping is often possible but rarely used. Microsoft’s post-incident guidance pointed customers to role-based access control for applications in Exchange Online, which limits an app to the specific mailboxes it needs. A mail-archiving tool may need every mailbox. A shared-inbox automation needs one. Many vendors ask for the broadest permission because it is easiest to document, and customers grant it because the project is late. Narrowing it later is harder than narrowing it at the start.

Procurement can help. Contracts and security questionnaires for SaaS integrations can require the vendor to list the exact permissions its app requests, justify each one, and support scoping. Regulated buyers already have a hook for this. US banking regulators’ 2023 interagency guidance on third-party risk management expects banks to assess the access a third party will have. Health systems sign business associate agreements with vendors that handle protected health information. Agencies authorize cloud services before use. In each case the permission an app holds in the tenant is part of what is being approved, and it should be written down.

A pilot that never closed

Suppose that five years ago a regional health system’s digital team set up a test tenant to pilot a patient-messaging tool. To make the pilot work, a developer registered an app and an administrator in the main tenant granted it permission to read and send mail on behalf of any user. The pilot ended. The developer moved on. The test tenant was never closed, and its admin account still signs in with a password alone.

On paper, the health system has strong security. Its main tenant requires MFA for every clinician. But an attacker who sprays passwords across its domains finds the old test account, signs in, and discovers the app. Because the app holds a tenant-wide permission in production, the attacker can now read executive and clinical email without touching a single protected account. Every control on the main tenant worked perfectly, and none of them mattered.

Now run the three questions. Who can log in? Anyone with the password, from anywhere. What can it reach? Every mailbox in production. Who would notice? Nobody had a rule watching that app. Three bad answers, the same pattern Microsoft described.

Who would notice: detection on non-human activity

The third property is visibility. The actor’s actions were unusual for the identities involved. A dormant test application suddenly created new applications. A newly created account granted consent. New applications were assigned a powerful mailbox role. Each of those actions produced audit records, the system’s own diary of who did what and when. The question for any security team is whether anyone was looking at them.

Most detection content was built around users: impossible travel (the same person signing in from two continents an hour apart), unusual sign-in locations, risky sign-ins. Non-human identities need their own rules. A useful starting set flags new credentials added to an existing app and new high-privilege permissions granted to any app. It also flags role assignments to service principals and any activity from an app dormant for months. These events are rare in a well-run tenant, so the alert volume is manageable.

The logs that answer the question

Three kinds of record matter. Directory audit logs show changes: an app created, a credential added, consent granted, a role assigned. Service principal sign-in logs show when an app authenticated, from where and to what. Mailbox audit records show which messages were accessed. Microsoft’s January guidance pointed to alerts for apps with application-only permissions reading large volumes of email, and for a jump in an app’s calls to Exchange after a credential change. It also flagged the full_access_as_app role being granted with admin consent.

Each of those depends on the logs being collected, kept and searched. Mail access records were a premium audit feature until Microsoft, after the separate Storm-0558 intrusion in 2023, said it would make them available to standard customers. Retention matters too. An intrusion that began months before detection, as HPE’s did, can only be scoped if the logs reach back that far. Sending these logs to a central security platform costs money, and service principal and mail access logs are high-volume. That cost is a reason to choose carefully what to keep, not a reason to keep nothing.

Testing the rules and the response

A detection rule that has never fired is an assumption. The simplest test is to make a harmless change on purpose: add a credential to a test app, grant it a low-risk permission, or sign in with it from an unusual place. Then check whether the alert arrived, who saw it and how long it took. Repeating the test each quarter catches rules that broke when a log source changed.

The response needs a playbook as well. When an alert fires on a high-privilege app, the first steps are to remove the new credential, disable the service principal if its owner cannot vouch for the change, and review recent consents and role assignments. Mailbox access records then show what the app read. Each step is quick if the app has a known owner. Without one, the team must decide whether to disable an app nobody can explain, at the risk of breaking an integration someone depends on.

Who watches depends on who you are

A large bank or health system with its own security operations center can write and tune these rules itself. A credit union, a small hospital or a county government usually relies on a managed security provider. For them the practical step is contractual: confirm that the provider’s detection content covers app and service principal activity in Microsoft 365, and that it collects the logs needed to see it. Many managed services were built to watch endpoints and user sign-ins, and the gap is easy to miss.

There is a trade-off. Tight monitoring of app activity generates work for identity and security teams who already struggle with user alerts. The answer is to tier: watch the small set of highly privileged apps continuously, and review the long tail in a quarterly attestation by app owners. An attestation is simply a formal confirmation, signed by the person responsible, that the app is still needed and its permissions are still right.

How it happens in practice: the life of a forgotten app

The pattern requires no carelessness on anyone’s part. It is the natural result of how cloud services get used inside busy organizations, and its life cycle runs roughly as follows.

It starts with a reasonable request. A project team wants to try something new: an automated mail sorter, a reporting dashboard, a connector to a supplier’s system. Setting up a test tenant takes minutes and needs no purchase order. Registering an app takes minutes more. To make the demonstration work convincingly, the team asks an administrator for real permissions in the main tenant, and the administrator, wanting to help, grants them.

Then the project changes shape. It is cancelled, or it succeeds and is rebuilt properly elsewhere, or its sponsor leaves. The test tenant and the app are not part of anyone’s handover checklist, because nobody thinks of them as assets. They do not appear on the balance sheet, they cost little or nothing to keep, and they make no noise. Months pass, then years.

Meanwhile, the organization’s main security program matures. MFA is rolled out to every employee. Conditional access rules tighten. Access reviews become routine. All of this improvement happens in the main tenant, where the identity team works every day. The old test tenant never gets the upgrade, and the old app keeps its old permission. The gap between the well-defended front of the building and the forgotten side door grows wider with every improvement.

Finally, an attacker who is patient enough to look finds the side door. Password spraying is cheap and slow; it can run for weeks without drawing attention. When it finds a single account that accepts a password alone, it hands the attacker a starting point, and the stale permission does the rest.

A control at each stage

Each stage of that life cycle offers a natural control point. At creation, a request form records the business owner, the technical owner, the purpose, the requested permissions and an expiry date. At grant, any application permission in production goes through the same approval as a privileged role, with the reason recorded. In operation, the owners attest each quarter that the app is still needed. At a change of people, the leaver process checks whether the departing employee owns apps or tenants and reassigns them. At the end, the project closure checklist lists every tenant, app and grant the project created and removes them.

The weakest of these is usually the leaver step. Human resources systems know when someone leaves. They rarely know that the person owned an app registration. Linking the two, by reporting app ownership against the staff directory each month, catches orphans before they age.

Seen this way, the fix is not a heroic technology project. It is ordinary housekeeping, built into ordinary processes: approval before a tenant or a powerful app is created, an owner recorded at the moment of creation, an expiry date for test resources, and a closing step at the end of every project that removes what it created. These are the same disciplines organizations already apply to physical keys, building passes and bank signatories. The cloud simply makes it easier to hand out keys without anyone noticing.

The case against heavy governance

Engineering leaders raise a fair objection. Approval workflows for every test tenant and every app slow experimentation, and slow teams route around controls. A developer who must wait two weeks for a sanctioned sandbox may create one with a personal credit card instead, and that tenant will be invisible.

The answer is to make the governed path the fast one. Self-service sandboxes, created from a template with sign-in rules, logging and an expiry date already set, can be issued in minutes. Approval can be reserved for the one step that creates risk: granting a test app any permission in production. Most experiments never need that. The few that do are exactly the ones that deserve a second look.

What senior email holds

This is less a technical story about one vendor than a leadership story about any organization that runs on cloud services, which today is nearly all of them.

The money and risk are direct. Email at the senior level holds negotiations, legal advice, board discussions and security plans. A foreign intelligence service reading it can learn strategy, find openings for future attacks and gather intelligence on customers and partners. For a regulated firm, that can trigger disclosure obligations, regulatory inquiries and difficult conversations with clients. For a hospital or agency, it can expose information that individuals trusted the institution to protect.

The objection that this was about Microsoft

A reasonable reader might decide that a Russian intelligence service targeting Microsoft has little to do with a mid-sized bank or a county health department. The actor was unusually skilled and patient, and its target was unusually valuable.

The techniques, though, were commodity. Password spraying is run constantly by criminal groups against any organization with an internet-facing login. Abuse of OAuth consent is a common phishing technique: a user is tricked into granting a malicious app access to their mailbox. Over-privileged apps are found by anyone who gets a foothold and looks around. The skill in this case lay in patience and in knowing what to look for, not in tools. A smaller organization faces less determined attackers, but it usually also has fewer people watching for them.

Your secrets in someone else’s inbox

A supplier’s mailbox also holds the customer’s secrets. Support tickets and project emails often carry passwords, API keys, connection strings and configuration files sent to a vendor to fix a problem. Microsoft later said the actor was trying to use secrets of this kind found in its email. For a customer, that means a breach at a vendor can become a credential exposure at home, with no failure on the customer’s side.

The defense is old and unglamorous. Credentials should never travel by email; vendors should receive them through a secure channel or, better, through scoped access that expires. Any secret that has ever been emailed to a vendor should be treated as exposed and rotated on a schedule. When a major vendor reports a mailbox compromise, the first task is to search outgoing mail for credentials sent to that vendor, then rotate them.

What each sector has to disclose

The consequences of a mail compromise vary by sector. A public company weighs whether the incident is material for SEC purposes. A bank or credit union faces its regulator’s incident notification rules, which run on hours, not days. A health system must assess whether protected health information in the mail was compromised, which can trigger breach notification under HIPAA. An agency reports under federal incident rules. Organizations should work through their obligations with counsel, but the common requirement is the ability to say which mailboxes were accessed and what they held, which loops back to the logs.

There is also a governance lesson. Test environments and old apps tend to fall outside anyone’s budget and outside anyone’s accountability. They are created quickly by well-meaning teams to get a project moving, and then they persist long after the project ends. The cost of cleaning them up is small. The cost of not knowing they exist can be very large.

Answers from a report, not a research project

A well-run organization can answer three questions about any identity in a few minutes, using a report rather than a research project. It knows every tenant it owns and who is responsible for each. It applies the same sign-in rules everywhere, or blocks sign-in where it is not needed. It holds an inventory of apps by permission, with owners, and reviews the most powerful ones closely. It has detection rules aimed at software identities as well as at people.

Building the report

The data for that report already exists in the identity platform. Entra ID can list every app registration and service principal, the permissions each holds, who consented, the credentials attached and when each was last used. The work lies in joining that data across tenants, adding owners from the service catalog, and running it on a schedule. Some organizations build this with scripts against Microsoft’s directory APIs. Others buy a SaaS security posture management tool. Either way, the report should show a small number of measures over time.

Useful measures include the number of tenants and the share with a named owner. Another is the number of password-only accounts, by tenant. Others count the apps holding high-risk permissions and the share of them with a current owner attestation. The count of app credentials past their planned lifetime, and of apps unused for ninety days or more, completes the set. Each measure should point to a team that can move it.

The failures are familiar:

• Trusting the label. Calling something “test” and assuming that makes it harmless.
• Forgetting the side doors. Securing the main tenant thoroughly while pilot and acquired tenants keep their old, weaker settings.
• Permanent exceptions. MFA exclusions granted for a good reason years ago and never reviewed.
• Counting people, not permissions. Access reviews that cover every employee but ignore the apps that can read every mailbox.
• Orphaned apps. Integrations whose builder has left and which nobody now owns.
• User-only monitoring. Alert rules that would catch a strange human login but stay silent while an app creates new apps.
• Secrets by email. Credentials sent to vendors in plain messages and never rotated afterward.

What an executive can ask about tenants and apps

1. How many cloud tenants do we own, including test, pilot and acquired ones? Who owns each, and when was that list last checked?
2. How many accounts, across all tenants, can sign in from the internet with a password alone? Who approved each exception, and when do they expire?
3. Which apps can read all mail, change our directory or grant roles to other apps? Who owns each, and when did each last do anything?
4. Do any apps registered in a test or partner tenant hold permissions in our production tenant?
5. Would we receive an alert if a dormant app suddenly gained new credentials or new permissions? Who would see it, and how quickly?

Two process checks lie behind those: who can create a new tenant today, and whether that needs approval; and whose job it is, when a project ends, to remove the test tenants and apps it created. Applied together, the three questions give a simple rule. A test identity that cannot be reached from the internet, holds no cross-boundary privilege, and is monitored can stay lightly governed. One that fails any of the three needs production treatment, whatever its tenant is called.

Reading the answers

The first answers are often vague, and the vagueness is informative. A team that answers the tenant question with “we think about six” has no register. A team that can name the high-privilege apps but not their owners has an inventory without accountability. A team that says alerts exist but cannot say who received the last one has rules that nobody tests.

A reasonable first quarter of work follows the order of the questions. Find every tenant and assign owners. Remove password-only sign-in, starting with administrators and test tenants. Pull the list of apps with high-risk permissions and confirm or revoke each. Then add the handful of detection rules for app credential and permission changes, and test them by making a harmless change and checking that the alert arrives. The work needs no new platform. It needs a sponsor who will ask for the numbers every month until they stop surprising anyone.

With hindsight

The story widened. In March 2024 Microsoft said the actor had used information from the stolen emails to try to access, and in some cases access, source code repositories and internal systems. Source code is the human-readable recipe for software, among the most valuable assets a technology company owns. The stolen email became a map for going further.

The same March update added two details. The actor was trying to use secrets of various kinds found in the email, some of them shared between customers and Microsoft. And password sprays and related activity had increased by as much as tenfold in February compared with January. Microsoft said it had found no evidence that its customer-facing systems were compromised, and that it was contacting customers whose secrets had turned up.

In April 2024, CISA, the U.S. Cybersecurity and Infrastructure Security Agency, issued Emergency Directive 24-02. It required federal civilian agencies to analyze email they had exchanged with Microsoft that may have been exfiltrated, meaning copied out by the attacker, and to reset affected credentials. CISA called the situation a grave and unacceptable risk to agencies. Agencies had until the end of April to identify their correspondence with compromised accounts and to remediate credentials found in it. A breach at a supplier had become a security task for its customers, including the federal government. CISA later said the directive had served its purpose and retired it in January 2026.

That same April, the Cyber Safety Review Board published its review of a separate 2023 intrusion into Microsoft’s Exchange Online by a China-based actor, and concluded that Microsoft’s security culture was inadequate. The two episodes together put Microsoft under unusual public pressure.

Microsoft expanded its Secure Future Initiative in May 2024 and has since reported work to remove unused applications and tenants. In its September 2024 progress report it said it had eliminated 730,000 unused apps and 5.75 million inactive tenants. It also described a new system for test and experimentation tenants with secure defaults and enforced lifetime limits. That is a telling choice of priority: the clean-up was aimed at exactly the kind of forgotten assets that had opened the door.

Customers felt the change too. From October 2024 Microsoft began requiring MFA for sign-ins to the Azure portal and the Entra and Intune admin centers, and from February 2025 for the Microsoft 365 admin center. A second phase covering command-line and automation tools began in October 2025. Microsoft said there would be no exception for test tenants. But the enforcement does not apply to workload identities such as service principals. The second and third questions in this article, reach and detection for apps, stayed the customer’s job.

Federal agencies got their own tenant rule. In December 2024 CISA issued Binding Operational Directive 25-01, which required agencies to inventory their cloud tenants by February 2025 and apply mandatory secure configuration baselines, starting with Microsoft 365. Its scope was production and operational tenants, so test tenants remained a matter for each agency’s own governance.

The disclosure side also moved. In May 2024 the SEC’s Division of Corporation Finance said companies should use Item 8.01, not Item 1.05, of Form 8-K for cyber incidents not yet judged material. Form 8-K is the report public companies file to tell investors about significant events; Item 1.05 is the section for material cybersecurity incidents, and Item 8.01 is a general section for other events a company chooses to report. Organizations should work through their own disclosure approach with counsel.

Nothing in the later disclosures changed the technical picture: no novel exploit was needed, only an exposed test account and an over-privileged app. That is the uncomfortable and useful part. The defense did not require new technology. It required an organization to know what it had already created, to apply its own rules consistently, and to watch software identities as closely as people. Those are management disciplines, and they are within reach of any organization willing to make someone accountable for them.