In This Article
The company that sells and manages your Microsoft 365 tenant holds a set of keys to it. That is the whole point of working with a Microsoft Cloud Solution Provider: your team gets to focus on lending and member service while a specialist keeps the tenant running, patched, and configured the way it should be. On July 2, 2026, Microsoft made clear that those keys now come with conditions. In new guidance on securing its partner ecosystem, Microsoft tied a partner's very authorization to operate to the strength of that partner's own security posture.
For a bank, credit union, or mortgage lender, this is not abstract vendor news. Your Microsoft partner has delegated administrative access into the environment where your email, your documents, your member and borrower data, and your identity controls all live. If that partner is careless with its own security, its access becomes a path straight into your tenant. Microsoft's guidance reframes a question your examiners are already asking in third-party risk reviews: how much access does your Microsoft partner really have, and can you trust the way it is secured?
This article breaks down what Microsoft actually changed, why partners have become a favorite target for attackers, and the specific questions every institution should put to the firm that manages its Microsoft 365 tenant. The guidance is new. The exposure it addresses has been building for years, and the institutions that get ahead of it will be the ones that treat their Microsoft partner like the critical vendor it is.
What Microsoft Changed in July 2026
On July 2, 2026, Microsoft published guidance titled "Improving security posture across the Microsoft partner ecosystem," written by Raji Dani, a Vice President and Deputy CISO at Microsoft. The core message is a shift in how Microsoft treats the companies authorized to sell and manage its cloud services. Microsoft has evolved its Cloud Solution Provider program so that maintaining a strong security posture is now a mandatory requirement for obtaining and retaining authorization, not an optional best practice a partner can defer.
In plain terms, a partner can no longer resell and administer Microsoft 365 while running a weak security operation of its own. Microsoft is treating the partner channel as part of the attack surface that protects every downstream customer, because that is exactly what it is. The guidance describes several reinforcing controls: mandatory security requirements as a condition of authorization, tighter delegated access through granular permissions, the ability to rapidly revoke a partner's access when something goes wrong, and high-volume telemetry across Microsoft's platforms to detect activity that looks like an attack aimed at partners.
Why This Matters for Financial Institutions
Your Microsoft partner sits inside your regulatory perimeter whether your vendor management program formally accounts for it or not. Delegated administrative access to your Microsoft 365 tenant reaches your email, your files, your identity controls, and the audit logs an examiner will ask to see. Under the interagency guidance that the FFIEC member agencies apply to third-party relationships, an institution is expected to perform due diligence on a critical technology provider and monitor that relationship over its life. A weakly secured Microsoft partner is precisely the kind of concentrated, high-privilege relationship that guidance was written to address.
What makes this announcement worth acting on rather than filing away is the direction it signals. Microsoft is not asking partners to try harder. It is making a demonstrably strong security posture the price of continued access to the ecosystem. Institutions that ask their partner to show how it meets that bar will learn a great deal about the risk sitting quietly in their own tenant.
Why Your Microsoft Partner Is a Target
Attackers follow leverage, and a Microsoft partner is leverage. Compromise one bank and you are inside one bank. Compromise the partner that administers dozens or hundreds of Microsoft 365 tenants and you have a potential path into every one of them. Microsoft's guidance is candid about this: threat actors, including nation-state groups, deliberately target Cloud Solution Providers as a supply-chain route to reach the downstream customers those partners serve.
This is not a theoretical concern dressed up as a marketing hook. The broader breach data has moved in one direction for several years. Verizon's 2025 Data Breach Investigations Report found that the share of breaches involving a third party roughly doubled compared with the prior year, as attackers increasingly reached their victims through vendors, software supply chains, and service providers rather than by battering the front door directly. When the trusted middle of the supply chain becomes the target, the institution at the end of it inherits the risk.
Compromise one bank and you are inside one bank. Compromise the partner that manages a hundred tenants and you have a key that opens a hundred doors.
For financial institutions the stakes are higher than for a typical business, because the consequences are not just operational. A foothold obtained through a partner's delegated access can lead to business email compromise, fraudulent wire instructions, and exposure of nonpublic personal information protected under the GLBA Safeguards Rule. It also becomes an examination problem. When a regulator asks how you assured yourself that your technology providers were secure, "we assumed they were" is not an answer that survives a third-party risk review.
A credit union hands broad, standing administrative rights to the firm that set up its Microsoft 365 tenant years ago. Nobody has reviewed that access since. The firm uses a shared administrator account, without strong multi-factor authentication, to log into many client tenants from the same workstation.
An attacker phishes that shared account. Because the partner's access is broad and standing rather than scoped and time-limited, the intruder inherits sweeping control of the credit union's tenant in one step, alongside every other client that account can reach. The credit union did nothing wrong inside its own walls, and is breached anyway.
That scenario is the reason Microsoft is hardening the partner channel, and it is the reason the model of delegated access matters so much. The difference between a partner relationship that contains a breach and one that amplifies it comes down to how that partner's access is scoped, protected, and monitored.
GDAP and the Move to Least-Privilege Access
The mechanism that governs how a Microsoft partner reaches into your tenant is called Granular Delegated Administrative Privileges, or GDAP. GDAP lets a partner hold only the specific administrative roles it needs, for a limited period of time, rather than the sweeping, open-ended control that the older Delegated Admin Privileges model granted. It is Microsoft's least-privilege answer to the problem the scenario above describes.
GDAP is not new, and that is an important point to get right. Microsoft introduced granular delegated access and began moving partners off the old broad model back in 2022 and 2023, and it started retiring the legacy Delegated Admin Privileges approach in late 2023. What the July 2026 guidance does is reinforce and harden that direction, pairing least-privilege delegated access with mandatory partner security requirements and stronger tooling to monitor and revoke access. The trend line has been pointing at least privilege for years. Microsoft is now making it a condition of doing business rather than a recommendation.
The practical distinction between the old model and the current one is the difference between handing someone a master key and handing them a badge that opens only certain doors, only during their shift. The comparison below shows what that looks like for a partner's access to your Microsoft 365 tenant.
Broad, Standing Access (the old model)
- Open-ended administrative control across the whole tenant
- Access that persists indefinitely, whether it is being used or not
- Roles far broader than any single task requires
- Little visibility into what the partner can actually do
- Hard to revoke quickly when something goes wrong
- One compromised partner account can expose much or all of the tenant
Least-Privilege, Time-Bound Access (GDAP)
- Only the specific administrative roles the work requires
- Access limited to a defined duration, then it expires
- Scope matched to the task, reviewed rather than assumed
- Clear record of which roles the partner holds
- Access the customer can revoke when it needs to
- A compromised account exposes far less of the tenant
Microsoft's guidance also emphasizes that a partner's delegated access can be revoked rapidly when the situation calls for it, for example during an incident or when a partnership ends. That control matters. A least-privilege relationship you can also cut off quickly is a very different risk than a broad relationship that would take days to unwind. For an institution, the takeaway is that the model your partner uses is not a technicality. It is the single biggest factor in whether a problem at your partner becomes a problem in your tenant.
Least Privilege Is a Control You Can Verify
Least-privilege delegated access is not a slogan. In Microsoft Entra ID and the Microsoft 365 admin center, an institution can see which partner relationships exist, which administrative roles a partner holds, and revoke that access. If your team cannot readily answer which roles your Microsoft partner has in your tenant today, that gap is itself a finding worth closing.
What Every Institution Should Ask Its Microsoft Partner
You do not need to wait for a contract renewal or an examination to pressure-test this relationship. Microsoft's guidance gives every institution a natural reason to open the conversation, and the questions below separate a partner that takes its own security seriously from one that does not. Each maps to something a diligent third-party risk program should already be documenting.
- Do you use least-privilege, time-bound GDAP rather than broad standing access? The answer should be a clear yes, with a willingness to show which roles the partner holds in your tenant and for how long.
- How is your own administrative access protected? A partner administering your tenant should enforce phishing-resistant multi-factor authentication on its admin accounts and avoid shared logins. Their identity hygiene is your exposure.
- Can we see and revoke your access ourselves? You should be able to view the partner's delegated relationships in Microsoft Entra ID and the Microsoft 365 admin center, and revoke them without waiting on the partner.
- How do you meet Microsoft's mandatory partner security requirements? Since a strong security posture is now a condition of Microsoft authorization, ask the partner to describe how it satisfies that bar rather than simply asserting that it does.
- What monitoring do you run on your access to our tenant? Delegated activity should be logged and watched, so a misuse of partner access is detected quickly rather than discovered months later.
- Can you produce evidence an examiner will accept? Audit trails of administrative activity, access reviews, and incident response commitments should be available on request, not reconstructed after the fact.
These questions do more than satisfy a checklist. They surface the difference between a partner that has quietly kept broad, standing access for convenience and one that has done the work to operate on least privilege with proper controls. If the conversation is uncomfortable for your partner, that discomfort is information. The institutions that treat identity as their perimeter already understand this instinct. Our analysis of why identity is the new perimeter in Microsoft 365 explains why the account with the keys, including a partner's admin account, is now the thing an attacker goes after first.
Key Takeaway
Microsoft just made a strong security posture a condition of being an authorized partner. Use that as your cue to confirm your own Microsoft partner operates on least-privilege, time-bound delegated access, protects its admin accounts, and can hand you the evidence an examiner will ask for. The security of the firm that holds keys to your tenant is part of your security, not separate from it.
Getting the identity foundation right underneath all of this is what makes the difference. The same discipline that closes a partner-access gap also closes the gaps attackers exploit directly, which is why institutions that have tightened their Conditional Access configuration against password-spray attacks and moved toward phishing-resistant multi-factor authentication are in a far stronger position when they turn the same lens on their vendors.
The controls Microsoft is now requiring of partners are the same ones a well-run Microsoft 365 practice already lives by. Granular Delegated Administrative Privileges in Microsoft Entra ID scope a partner's access to only the roles a task needs, for a limited time. Phishing-resistant multi-factor authentication protects the administrative accounts that reach into customer tenants. Microsoft Purview provides the audit trail of who did what, and Microsoft Defender surfaces suspicious activity across the tenants a partner manages. The capability lives in the Microsoft platform. What separates partners is whether they actually operate this way for regulated institutions, and whether they can prove it.
How ABT Operates as Your Tier-1 CSP
Microsoft's guidance describes the operating model ABT was built around. ABT is a Tier-1 Microsoft Cloud Solution Provider that manages the Microsoft 365 and Microsoft Entra ID tenants of more than 750 banks, credit unions, and mortgage companies. Microsoft hosts the underlying infrastructure, and ABT manages the tenant on the institution's behalf, including the delegated administrative access this article is about. Where a customer runs workloads in Azure, ABT hosts and runs that Azure environment as the partner of record, on Microsoft's Azure platform. The precision matters here, because the whole subject is who holds delegated keys to your Microsoft 365 tenant and how those keys are secured.
A small internal IT team at a community institution rarely has the time to audit partner access, enforce least privilege, and monitor delegated activity on top of everything else it does. That is the work ABT takes off their plate. It lets the institution's technology staff focus on serving members and closing loans, while the partner relationship at the center of the tenant is operated the way Microsoft's guidance now expects.
ABT's model lines up with that guidance on the points that matter most:
- Least-privilege delegated access. ABT administers customer tenants through granular delegated access scoped to the work at hand, rather than the broad standing control that turns one compromised account into a full tenant takeover.
- Protected administrative identities. The accounts ABT uses to reach into customer tenants are protected with strong, phishing-resistant authentication, so a partner-side credential is far harder to turn into customer-side access.
- Continuous monitoring inside the tenant. Through the Guardian operating model and Guardian MxDR, ABT monitors identity and administrative activity in the Microsoft 365 and Entra ID tenant it manages, so misuse is caught rather than discovered later.
- Evidence an examiner will accept. Least-privilege access, access reviews, and the Microsoft Purview audit trail give an institution the third-party risk documentation regulators expect, rather than assurances it cannot show.
What separates ABT from a national reseller is vertical depth. The largest Tier-1 CSPs move Microsoft licenses at enormous scale but seldom specialize in financial services, and the regional IT shops that understand banking often lack Tier-1 CSP status or do not operate identity controls at this depth. ABT does this for financial institutions specifically. That is why the vendor-risk questions that catch a credit union off guard are ones ABT has already answered across its 750-plus institution footprint, and why the governance and audit controls a regulated institution needs are part of how it operates rather than an afterthought.
The takeaway for a bank, credit union, or mortgage executive is direct. The firm that manages your Microsoft 365 tenant holds real access to it, and Microsoft has just raised the bar on how that access must be secured. The fastest way to know where you stand is to ask your partner the questions above, and to have your own delegated-access configuration reviewed by a team that does this for regulated institutions every day.
Do you know how much access your Microsoft partner really has?
ABT reviews the delegated administrative access into your Microsoft 365 and Entra ID tenant, confirms it runs on least privilege, and shows you the identity and audit controls an examiner will ask for. Start with a Microsoft 365 security and partner-access assessment through M365 Guardian and Guardian MxDR.
Frequently Asked Questions
On July 2, 2026, Microsoft published guidance titled "Improving security posture across the Microsoft partner ecosystem." Its central change is that maintaining a strong security posture is now a mandatory requirement for a Cloud Solution Provider to obtain and retain authorization, rather than an optional best practice. The guidance also reinforces least-privilege delegated access through granular permissions, the ability to rapidly revoke a partner's access, and telemetry-based monitoring for attacks that target partners.
Granular Delegated Administrative Privileges, or GDAP, is Microsoft's least-privilege model for partner access. It lets a partner hold only the specific administrative roles a task requires, for a limited time, rather than the broad, open-ended control granted by the older Delegated Admin Privileges model. GDAP is not new: Microsoft introduced granular delegated access in 2022 and 2023 and began retiring the legacy DAP model in late 2023. The July 2026 guidance reinforces and hardens that least-privilege direction.
A partner that manages your Microsoft 365 tenant holds delegated administrative access to your email, files, identity controls, and audit logs. If the partner is compromised, that access can become a path into your environment, which is why Microsoft notes that threat actors, including nation-state groups, target Cloud Solution Providers to reach downstream customers. Broader breach data reflects the same shift: Verizon's 2025 Data Breach Investigations Report found the share of breaches involving a third party roughly doubled year over year. Your partner's security posture is effectively part of your own.
Ask whether the partner uses least-privilege, time-bound GDAP rather than broad standing access, how it protects its own administrative accounts, and whether you can view and revoke its access yourself in Microsoft Entra ID and the Microsoft 365 admin center. Ask how it meets Microsoft's mandatory partner security requirements, what monitoring it runs on its access to your tenant, and whether it can produce audit trails and access reviews an examiner will accept. Clear, evidence-backed answers indicate a partner operating the way Microsoft's guidance now expects.
ABT manages your Microsoft 365 and Microsoft Entra ID tenant as a Tier-1 Microsoft Cloud Solution Provider. Microsoft hosts the underlying infrastructure, and ABT manages the tenant on your behalf, including the delegated administrative access and identity controls that this guidance is about. Where a customer runs workloads in Azure, ABT hosts and runs that Azure environment as the partner of record, on Microsoft's Azure platform. Through the Guardian operating model and Guardian MxDR, ABT operates that access on least privilege and monitors the tenant continuously.