In This Article
- What shadow IT is actually telling you
- The two kinds of shadow IT in a Microsoft 365 tenant
- Finding the apps: Defender for Cloud Apps discovery
- The path no traffic log will show you
- Sanction, unsanction, and actually blocking
- What your examiner asks for, by charter
- Making it a loop instead of a project
- Frequently Asked Questions
Somewhere in your institution, a loan processor got tired of waiting. The approved tool did not do the one thing she needed at 4:40 on a Friday, so she found something that did, signed up with her work email, and moved on with her afternoon. She was not being reckless. She was being effective.
That is shadow IT, and the instinct to treat it purely as a discipline problem is what keeps institutions stuck. The apps your staff adopted without asking are the most honest product requirements document you will ever receive. Every one of them marks a place where the sanctioned toolset did not carry the work, and somebody cared enough about getting the job done to route around it.
The problem is not that people found tools. The problem is that nobody can name them. And an app nobody can name is an app nobody vetted, nobody contracted, and nobody is monitoring. Whether any given one is holding borrower documents or member account details is precisely the thing you cannot answer until you look, which is the whole problem in one sentence. This article is about finding them with Microsoft tooling, deciding which ones to keep, and turning the whole thing into a routine your examiner can see.
One thing to settle first, because it changes the shape of the project. Everything below runs on Microsoft Defender for Cloud Apps, which is not part of Microsoft 365 Business Premium. Business Premium, scoped by Microsoft to organizations up to 300 users and run by a great many community banks, credit unions, and mortgage companies, includes Microsoft Entra ID P1, Intune Plan 1, Defender for Business, and Defender for Office 365 Plan 1. Defender for Cloud Apps arrives with the add-on Microsoft calls Microsoft Defender Suite for Business Premium, which Microsoft's own documentation describes in exactly the terms this article is about, saying the capability "enables IT teams to identify and manage shadow IT and ensure that only approved applications are used." That same add-on brings Defender for Endpoint Plan 2, which matters later, because it is one of the three ways to turn an unsanctioned tag into an actual block, and the one that comes in the box. So this is a licensing decision sitting in front of a discovery decision. As a Tier-1 Microsoft Cloud Solution Provider, ABT prices it both ways, so the answer comes back as arithmetic rather than a guess.
What shadow IT is actually telling you
Shadow IT is any technology in use inside the institution that IT did not approve, does not manage, and often does not know exists. In practice that means software as a service: a file transfer site, an e-signature trial, a note-taking app, a personal cloud drive, a scheduling tool, a spreadsheet add-in, an AI assistant.
Read the list the right way and it is a roadmap. If four people in servicing independently signed up for the same document collection tool, that is not four policy violations. That is a gap in your loan file intake, described precisely, by the people closest to it, for free. The institutions that handle shadow IT well treat the first discovery report as a product conversation before they treat it as a security incident.
Then they treat it as a security conversation, because the second half is real. The convenience that made the tool attractive is the same property that makes it dangerous: it accepted a work email address, it never asked anyone's permission, and it now holds data it was never authorized to hold.
Why this lands differently at a financial institution
At most companies an unsanctioned app is an IT hygiene issue. At a bank, credit union, or mortgage company it is also a third party holding nonpublic personal information under no contract. That changes it from a cleanup task into something with a regulator attached, which is why the ending of this article is a routine rather than a one-time sweep.
The two kinds of shadow IT in a Microsoft 365 tenant
Most shadow IT guidance covers only the first of these, which is why so many institutions clean up thoroughly and still have a hole.
The first kind is network shadow IT. Someone visits a website, creates an account, and starts uploading. The traffic leaves your network and shows up in firewall and proxy logs. This is the classic case, and it is the one cloud discovery was built to find.
The second kind never touches an unapproved domain at all. An employee grants a third-party application permission to their Microsoft 365 account. From that moment the app talks directly to Microsoft Graph, reading mail, files, and calendars through Microsoft's own front door with a valid token. Nothing anomalous appears in a proxy log, because from the network's point of view the traffic is going to Microsoft, which it is supposed to do.
The riskiest app in your tenant may never have generated a single suspicious network connection. It was invited in, and it has a key.
Both kinds need finding, and Microsoft addresses them with two different features. Skipping either one leaves a category of exposure completely unexamined. We cover network discovery next, then the consent path.
Finding the apps: Defender for Cloud Apps discovery
Cloud discovery in Microsoft Defender for Cloud Apps analyzes your traffic logs against a catalog of over 31,000 cloud apps, ranked and scored on more than 90 risk factors. It answers the question most institutions cannot answer today: what is actually being used here, by how many people, moving how much data.
There are three practical ways to feed it, and the one you choose mostly depends on what you already run:
The native integration. If your endpoints are already onboarded, this is the lowest-effort path, and it follows the device off the corporate network.
Runs on your network and receives logs over Syslog or FTP from firewalls and proxies. Microsoft supports a long list of appliances including Palo Alto, Fortinet, Cisco, Check Point, and SonicWall.
Direct integrations with Zscaler, iboss, Corrata, Menlo Security, and Open Systems, if you already route traffic through one.
You can start with a snapshot report, which is an ad hoc look at a set of logs you upload by hand, before committing to continuous reporting. For a first conversation with your executive team, a snapshot is usually enough to make the point. Continuous reports are what you want once you are ready to run this as a program, and discovery data is analyzed and updated four times a day.
One honest limitation to carry into the room with you: by default, Defender for Cloud Apps cannot discover apps that are not in its catalog. Thirty one thousand apps is broad coverage, not total coverage. A genuinely obscure or brand new service can be missed, and custom apps have to be defined manually. Anyone who tells you a discovery tool finds everything is selling you something.
The path no traffic log will show you
This is the half that gets skipped, and it is the half with an active threat campaign behind it.
When an employee consents to a third-party application, that app receives standing permission to reach Microsoft 365 data on their behalf. App governance in Defender for Cloud Apps is where you see those applications, and for OAuth apps registered in Microsoft Entra ID it shows a genuinely useful set of signals:
- A risk score from 1 to 100, where higher means greater risk, so you have a defensible way to triage rather than reviewing an alphabetical list
- Whether the app has unused Microsoft Graph API permissions over the last 90 days, which is the fastest way to spot an app holding far more access than it exercises
- Total data downloaded or uploaded over the last 30 days across Exchange, SharePoint, OneDrive, and Teams
- Consent type, showing whether a user or an administrator approved it, and how many users' data the app can reach
- Which sensitivity labels appear on the content the app has touched
- The publisher and whether that publisher is verified
Read those together and the review almost writes itself. An app with a high risk score, admin consent across the whole tenant, permissions it has not used in 90 days, and an unverified publisher is not a hard call.
In campaigns observed between mid-2025 and mid-2026, Microsoft identified threat actor activity with tradecraft commonly associated with ShinyHunters that used voice phishing to impersonate IT support staff and walk employees through the OAuth consent workflow. In several confirmed cases the malicious application was disguised as a legitimate Salesforce Data Loader tool. Microsoft reports that abuse of these access paths led to inherited user and application privileges, allowing enumeration and querying of customer relationship management records while evading conventional authentication detections. Microsoft states the activity was not the result of a vulnerability in Salesforce. The tenants Microsoft named span retail, education, and manufacturing.
Financial institutions were not among the industries Microsoft named in that reporting, and it would be dishonest to imply otherwise. What matters is that the mechanism is indifferent to your charter. It requires only an employee with a mailbox, a convincing phone call, and a consent screen. Every institution reading this has all three. If you want the anatomy of that consent screen and the specific tenant settings that blunt it, our walkthrough of OAuth consent phishing that bypasses multifactor authentication goes deeper than we can here.
Microsoft's own hardening guidance starts in the same place: configure user consent settings so that users can only consent to applications meeting criteria you set, such as applications from verified publishers or developed in house, and only for low risk permissions you select. Everything else routes to an admin consent workflow, which you enable alongside it. Turn on the restriction without the workflow and users simply hit a dead end, which is the exact route around IT that started this whole problem. Enable both and an invisible decision made by one employee under pressure becomes a reviewable request.
Which leaves the question the tooling does not answer on its own: who is reading the alert. A consent grant that lands while nobody is looking at the console is only a finding if somebody opens it before the token gets used, and app governance will happily accumulate risk scores that nobody reads. That gap, between owning the license and running the discipline, is the entire reason managed detection and response exists. For the institutions ABT manages, running that review is what Guardian MxDR is for.
Microsoft Entra ID disables applications it confirms have violated its terms of service, tenant wide. New token requests are denied, though existing access tokens stay valid until they expire, which is why revoking sessions matters. The disabled objects carry a status of DisabledDueToViolationOfServicesAgreement and cannot be deleted, so they cannot be quietly reintroduced later. If anyone in your organization had consented to the app, a Privileged Role Administrator receives an email.
Sanction, unsanction, and actually blocking
Once you can see the estate, Defender for Cloud Apps lets you tag each discovered app as sanctioned or unsanctioned. Here is the detail that catches people out, and it is worth reading twice.
Marking an app unsanctioned does not block it. On its own, the tag is a monitoring aid that makes the app easy to filter and track. Blocking is a separate step, and it comes from one of three places:
- Microsoft Defender for Endpoint. Where your tenant uses it, apps you mark unsanctioned are blocked automatically. You can scope blocking to specific device groups, which are defined in the Microsoft Defender portal from devices already onboarded to Defender for Endpoint, so the scoping is only ever as good as your onboarding coverage. There is also a warn and educate experience that tells the user why rather than failing silently. This requires Cloud Protection and Network Protection turned on in Defender for Endpoint, plus the Microsoft Defender Browser Protection add-on installed in any non-Microsoft browsers your staff use.
- A supported secure web gateway. Zscaler, iboss, Corrata, Menlo, and Open Systems will also block unsanctioned apps, though without the device group scoping or the warn and educate experience.
- An exported block script. For everything else, generate a block script for your on premises appliance and import it, which avoids redirecting all of your web traffic through a proxy.
A short warning on enthusiasm. The first discovery report is going to surface a number of apps, and the temptation is to block broadly and sort it out afterward. Resist it. Some of what you find will be load bearing for a team that never told you, and breaking a servicing workflow on a Tuesday morning teaches your staff that the security team is something to route around, which is precisely the behavior that created the problem. Sanction the obvious keepers, block the genuinely dangerous, and put the ambiguous middle into a conversation.
Not sure what is running in your tenant right now?
Most institutions have never run a discovery pass. The first one is usually the most interesting report your IT committee sees all year.
What your examiner asks for, by charter
Here is where shadow IT stops being an IT problem. Two obligations show up in every information security regime that covers credit unions, banks, and mortgage companies: know the systems that touch customer or member data, and oversee the third parties that hold it. An unsanctioned app breaks both at the same time. It is a system nobody inventoried, operated by a service provider nobody selected, bound by no contract, and reviewed on no schedule.
The obligations are common because they descend from the same statute, the Gramm-Leach-Bliley Act. What differs is which agency enforces them against you, and therefore which citation your examiner opens. This is worth getting right, because the wrong citation in a board paper is the kind of thing that undermines an otherwise solid presentation.
| If you are a | Your authority | Inventory and risk obligation | Service provider obligation |
|---|---|---|---|
| Mortgage company or other non-bank lender | FTC Safeguards Rule, 16 CFR Part 314, which applies to financial institutions under FTC jurisdiction, meaning those not subject to another regulator under GLBA section 505 | 314.4(c)(2): identify and manage the data, personnel, devices, systems, and facilities that enable you to achieve business purposes, according to their relative importance and your risk strategy. Its sibling 314.4(c)(8) then asks you to monitor and log the activity of authorized users, which is the other half of the same problem | 314.4(f): select and retain providers capable of maintaining appropriate safeguards, require those safeguards by contract, and periodically assess them based on the risk they present |
| Bank | Interagency Guidelines Establishing Information Security Standards, codified separately by each agency: OCC at 12 CFR Part 30 Appendix B, FDIC at 12 CFR Part 364 Appendix B, Federal Reserve at 12 CFR Part 208 Appendix D-2 | Section III.B: identify reasonably foreseeable internal and external threats to customer information and customer information systems, and assess the sufficiency of the arrangements in place to control those risks | Section III.D: exercise appropriate due diligence in selecting service providers, require appropriate measures by contract, and monitor them where the risk assessment indicates |
| Federally insured credit union | NCUA Guidelines for Safeguarding Member Information, 12 CFR Part 748 Appendix A. A privately insured credit union is not covered here; it falls under the FTC rule in the first row, which names non-federally insured credit unions explicitly | Section III.B.1: identify reasonably foreseeable internal and external threats to member information and member information systems | Section III.D: due diligence in selection, contractual requirements, and monitoring including review of audits, summaries of test results, or equivalent evaluations |
Three notes on reading that table. The banking rows are one common set of guidelines that each agency publishes in its own part of the code, so which citation applies depends on your charter and primary federal regulator, not on anything about your security program. The credit union row says member information where the banking rows say customer information, and using the wrong noun in front of an examiner is a small unforced error. And the FTC rule does not reach banks or federally insured credit unions, though it does reach privately insured ones, which 16 CFR 314.1(b) names outright. That last detail is worth knowing if you have ever been handed a Safeguards Rule checklist by a vendor who did not check your charter, and it cuts both ways: the checklist is wrong for most credit unions and right for a few.
We keep that table straight because we are not generalists working from a checklist. ABT manages Microsoft 365 tenants for more than 750 credit unions, banks, and mortgage companies, so the difference between a Safeguards Rule shop and an NCUA shop is not a research task at the start of an engagement. It is the vocabulary.
What no product can do for you
None of these regulations can be satisfied by buying something. Each requires a program: a documented risk assessment, written policies, controls that follow from that assessment, service provider oversight, testing, and reporting to your board or management. Microsoft 365, Defender for Cloud Apps, and any managed service built on them, including ours, are evidence toward specific controls inside that program. Any vendor who tells you their product makes you compliant with GLBA, the NCUA guidelines, or the interagency guidelines is describing something that does not exist.
What discovery does give you is the raw material those programs are missing. It converts "we believe staff only use approved applications" into a dated inventory with names, user counts, and data volumes, which is a considerably better answer than the one most institutions can give today. If you are working toward a broader examination, our guide to FFIEC IT examination readiness covers where this evidence sits alongside everything else, and credit unions preparing specifically for their next cycle may want what NCUA examiners actually look for.
Making it a loop instead of a project
Shadow IT is not a backlog you burn down. Staff will keep finding tools, because staff will keep having problems, and the day discovery stops surfacing anything new is the day something has broken in your collection pipeline. So the goal is a loop that runs on a schedule.
A workable rhythm for an institution of almost any size looks like this. Run discovery continuously and review the report monthly, treating anything new and high risk as an exception to handle now. Review OAuth applications quarterly, starting with the highest risk scores and any app holding permissions it has not used in 90 days. Revisit your user consent settings annually, or immediately after any consent phishing attempt. Feed the resulting inventory into the same third party risk process your examiner already reviews, so it is not a parallel artifact nobody else can find.
That cadence is the whole job, and it is also why so many institutions run the first discovery pass and never run the second. The first one is interesting. The fourth one is a Tuesday task competing with a core conversion and an audit response, and it loses. M365 Guardian is how ABT runs this as a standing discipline instead of a project: we configure the Microsoft controls behind it, hold the tenant against a fixed policy baseline, and bring you the drift rather than waiting for someone to go looking for it.
There is a second thing that only shows up at scale. Across more than 750 credit unions, banks, and mortgage companies, the same short list of applications keeps surfacing in the same places, in servicing, in origination, and at the branch. Knowing which of the thirty one thousand catalog entries actually turn up in an institution shaped like yours, and which of them are worth having the argument with the department that adopted them, is not something your first discovery report can tell you. It is the kind of thing you only learn by reading a lot of first discovery reports.
The pieces connect to work you may already have underway. Sensitivity labels tell you which discovered apps have been touching your most sensitive content, which is why classifying nonpublic personal information with Microsoft Purview makes every later shadow IT review sharper. Data loss prevention decides what can leave through the apps you keep, covered in our DLP configuration guide. And the AI specific slice of this problem, staff pasting member data into consumer chatbots, has its own dynamics that we treat separately in shadow AI in banking.
The short version
Run discovery on the network side and app governance on the consent side, because each one is blind to the other's category. Read the first report as a product requirements document before you read it as a violation list. Remember that unsanctioning does not block. Then put the review on a calendar, because the inventory obligation and the service provider obligation in your charter's guidelines are continuing duties, not a one time cleanup.
The institutions that get this right are rarely the ones with the most tooling. They are the ones who stopped being surprised, because they decided to look on a schedule and to ask why each app appeared before deciding whether it stays.
Find out what is actually running in your Microsoft 365 tenant
ABT manages Microsoft 365 tenants for more than 750 credit unions, banks, and mortgage companies. We can run a discovery pass, risk score what it finds, and help you decide what to sanction, what to block, and what to go build properly.
Frequently Asked Questions
Shadow IT is any technology in use inside an organization that the IT function did not approve, does not manage, and often does not know exists. In a financial institution it is usually software as a service that an employee signed up for with a work email address, such as a file transfer site, an e-signature trial, a personal cloud drive, or an AI assistant. It also includes third-party applications that an employee granted permission to reach their Microsoft 365 account.
Use two features together. Cloud discovery in Microsoft Defender for Cloud Apps analyzes traffic logs against a catalog of over 31,000 cloud apps scored on more than 90 risk factors, which finds apps reached over the network. App governance in the same product shows third-party OAuth applications registered in Microsoft Entra ID that were granted access to Microsoft 365 data directly. Network discovery alone will miss the consent-based apps entirely, because that traffic goes to Microsoft rather than to an unapproved domain.
No. On its own, the unsanctioned tag enables monitoring and filtering rather than blocking. Blocking comes from one of three sources: Microsoft Defender for Endpoint, which blocks unsanctioned apps automatically and can scope blocking to specific device groups; a supported secure web gateway such as Zscaler, iboss, Corrata, Menlo, or Open Systems; or an exported block script imported into an on-premises appliance. The Defender for Endpoint path requires Cloud Protection and Network Protection enabled, plus the Microsoft Defender Browser Protection add-on in non-Microsoft browsers.
It depends on your charter, because the Gramm-Leach-Bliley Act assigns enforcement to different agencies. Mortgage companies and other non-bank lenders fall under the FTC Safeguards Rule at 16 CFR Part 314, where 314.4(c)(2) covers identifying and managing systems and 314.4(f) covers service provider oversight. Banks fall under the Interagency Guidelines Establishing Information Security Standards, codified by the OCC at 12 CFR Part 30 Appendix B, the FDIC at 12 CFR Part 364 Appendix B, and the Federal Reserve at 12 CFR Part 208 Appendix D-2. Federally insured credit unions fall under the NCUA Guidelines for Safeguarding Member Information at 12 CFR Part 748 Appendix A, while privately insured credit unions are named in the FTC rule instead, at 16 CFR 314.1(b). All of these regimes require both an understanding of the systems handling customer or member data and oversight of the third parties holding it.
No. Every one of these regimes requires a program rather than a product: a documented risk assessment, written policies, controls that follow from the assessment, service provider oversight, testing, and reporting to the board or senior management. Tools such as Microsoft Defender for Cloud Apps produce evidence supporting specific controls inside that program. Treat any claim that a product delivers compliance with GLBA, the NCUA guidelines, or the interagency guidelines as a claim to verify carefully.
A practical cadence is to run discovery continuously and review the report monthly, handling anything new and high risk as an exception immediately. Review OAuth applications quarterly, prioritizing the highest risk scores and any application holding Microsoft Graph permissions it has not used in the last 90 days. Revisit user consent settings annually or right after any consent phishing attempt. Because the underlying obligations to inventory systems and oversee service providers are continuing duties, a review schedule is easier to evidence than a one-time cleanup.