Microsoft 365 Encryption for Financial Institutions

Your loan officers send borrowers tax returns, pay stubs, and closing disclosures every hour of the business day. Your members and customers expect that data to move quickly and arrive without friction. Microsoft 365 lets your team do exactly that, and it encrypts a great deal of that data automatically. So when an examiner asks how you protect customer information by encryption, it is tempting to answer that Microsoft handles it.

That answer is half right, and the half that is missing is the half examiners check. Microsoft 365 encrypts data on its disks and across the wire by default. It does not, by default, guarantee that the content of an email leaving your tenant stays encrypted and bound to the right recipient, or that a sensitive file shared in Teams stays protected after someone downloads it. That difference is the difference between a control you can describe and a control you can prove.

This guide walks through what Microsoft 365 encrypts on its own, where the gap sits, and the specific Microsoft controls that turn default encryption into the documented, examiner-ready posture that the FTC Safeguards Rule and the banking agencies expect. It is written for the people who get the exam findings: the IT directors, security leads, and compliance officers at credit unions, banks, and mortgage companies.

The encryption rule examiners actually enforce

For non-bank financial institutions, the encryption requirement is not a best practice or a framework suggestion. It is a categorical line in the FTC Safeguards Rule, and it has been enforceable since June 9, 2023, the compliance deadline for the rule's revised provisions. The text is short and specific.

Read it closely, because two details decide whether your posture holds up. First, the requirement is for data both in transit over external networks and at rest. Not one or the other. An institution that encrypts its servers but lets sensitive email content travel unprotected has covered half the rule. Second, there is exactly one exception. If your institution determines that encryption is infeasible for a particular system, the rule allows you to substitute effective alternative compensating controls, but only when those controls are reviewed and approved by your Qualified Individual, the person the rule makes accountable for your information security program.

That exception is the honest nuance, and it is the one examiners apply in practice. There is no informal waiver. If encryption is off somewhere, an examiner expects to see a documented infeasibility determination, a documented compensating control, and the Qualified Individual's documented approval. "Microsoft encrypts it" is not that documentation.

If you want the full picture of how the Safeguards Rule maps onto a Microsoft 365 tenant, our companion guide on the FTC Safeguards Rule for mortgage companies using Microsoft 365 walks the rule element by element. Encryption is one piece of a larger program, and the program is what the exam grades.

Who the mandate covers: the bank, credit union, and mortgage split

Here is where a lot of well-meaning compliance copy goes wrong, and where getting it right earns you credibility. The FTC Safeguards Rule does not apply to every financial institution. It applies to non-bank financial institutions under the Federal Trade Commission's jurisdiction. That includes independent mortgage lenders and brokers, auto dealers that arrange financing, and similar non-depository lenders. It does not cover banks or federally insured credit unions.

Banks and credit unions are not off the hook for encryption. They sit under a parallel regime: the information security standards that implement Section 501(b) of the Gramm-Leach-Bliley Act, written as the Interagency Guidelines Establishing Information Security Standards. Each prudential regulator publishes its own version of those guidelines.

The risk-based framing matters, but it does not soften the encryption expectation. The NCUA's Appendix A, the "Guidelines for Safeguarding Member Information," names the control directly as one of the measures a credit union should consider.

So the practical answer is the same across all three institution types, arrived at through two different doors. A mortgage company faces a categorical mandate. A bank or credit union faces a risk-based guideline that expressly expects encryption in transit and in storage. In both cases, an examiner will ask the same question: show me how customer or member information is encrypted, and show me where you decided it was not. The Microsoft 365 controls that answer that question are identical regardless of which door you came through.

What Microsoft 365 already encrypts by default

Start with the good news, because it is real and your institution is not starting from zero. Microsoft 365 encrypts customer data at rest by default. It uses BitLocker for volume-level disk encryption in Microsoft's data centers, Distributed Key Manager for key management, and additional service-level encryption across Exchange Online, SharePoint, OneDrive, and Teams files. The cryptography relies on FIPS 140-2 validated modules. By default, the keys are Microsoft-managed.

Data in transit is encrypted too. Microsoft 365 uses Transport Layer Security by default, and Exchange Online negotiates TLS 1.2 for mail transport. When your staff opens Outlook, when a file syncs to OneDrive, when one Microsoft server talks to another, that traffic is protected in transit.

This is the point where a lot of vendor messaging overreaches in one of two directions. Some claim Microsoft 365 is fully encrypted end to end, which is not accurate and will not survive an auditor's follow-up question. Others claim Microsoft 365 email is not encrypted, which is equally wrong and needlessly alarming. Neither framing is useful. The accurate framing is narrower and more important: default encryption protects data at rest on Microsoft's infrastructure and protects connections in transit, and there is a specific category of risk that default encryption alone does not close.

The gap between default encryption and an examiner-ready posture

The gap lives at the moment data leaves your tenant. TLS protects the connection between two servers. It does not protect the message content once the message lands, and it does not control what happens to that content afterward. When Exchange Online delivers email to a non-Microsoft server, the transport is only as protected as the receiving server allows. External mail transport is frequently opportunistic, meaning it uses TLS when the receiving server supports it and falls back when it does not, unless you enforce otherwise.

So consider what actually happens to a borrower's data on a normal day.

Now add the threat reality. The Verizon 2024 Data Breach Investigations Report found that the human element was involved in 68 percent of breaches. Stolen credentials and phishing remain among the top breach actions year over year. This is the part that reframes the encryption conversation. At-rest encryption is transparent to anyone who is logged in: BitLocker protects the disk from physical theft, but it does nothing to limit what a user can see once they have authenticated. So the at-rest layer alone does not narrow who can reach a given file, and it does not follow the data when that file leaves the tenant. Those are the two exposures content-level controls are built to address.

At-rest disk encryption protects your data from a stolen hard drive. It does not narrow who can open a sensitive file, and it does not follow the file out the door. Content-level encryption with access control does both.

Sensitivity labels and message encryption are not a cure for a compromised account that already has rights to a file. What they do is limit access to specific identities, so the population that can open a labeled document is small and deliberate rather than everyone in the tenant, and they keep the encryption and permissions attached to the content after it is sent or downloaded. That is why the examiner-grade control is not "is the disk encrypted." It is "is the sensitive content encrypted, scoped to the right people, and able to travel safely outside the tenant, and can you prove it." Closing that gap is a configuration exercise, and the tools to do it are already in Microsoft 365.

The Microsoft 365 controls that close the gap

Three Microsoft 365 controls turn default encryption into a content-level, recipient-bound, examiner-ready posture. None of them require a new platform. They require configuration, rollout, and documentation in the tenant you already run.

Microsoft Purview Message Encryption, the successor to what was branded Office 365 Message Encryption, encrypts the message itself, not just the connection. When that loan officer sends a closing disclosure, the content is encrypted and tied to the intended recipient. With Do Not Forward applied, the borrower can read it but cannot forward it onward. This is the control that turns the email scenario above from "we hope the receiving server used TLS" into "the content was encrypted to the recipient, and we can show the policy that did it."

The second control protects files wherever they go.

A sensitivity label is a piece of metadata that carries encryption and access rules with the file. Label a tax return "Confidential," and the encryption and permissions travel with the document. If that file is downloaded from Teams, copied to a USB drive, or attached to an email, it stays encrypted and only authorized identities can open it. The protection is bound to the content, not to the location, which is exactly the property the borrower-data scenario was missing. Sensitivity labels work hand in hand with data loss prevention, and our guide on Microsoft 365 data loss prevention for financial services covers how labeling and DLP policies reinforce each other.

The third control hands you the keys.

By default, Microsoft manages the encryption keys. Customer Key lets your institution supply and control the root keys instead, stored in your Azure Key Vault. For a board or an examiner asking who holds the keys to member data, "we do, and here is the key vault" is a materially stronger answer than "Microsoft does." Customer Key adds a layer of encryption using your own keys on top of the default service encryption.

Notice the arc across these three controls. Message Encryption protects what your team sends. Sensitivity labels protect what your team stores and shares. Customer Key proves who controls the keys. Together they take the productivity your team already has, keep the data protected as it moves, and produce the governance evidence the exam wants. For the email and file retention side of that evidence, see our guide on Microsoft 365 data retention and email archiving for financial institutions.

Default Microsoft 365 encryption is the floor. Microsoft Purview Message Encryption, sensitivity labels, and Customer Key build the examiner-ready posture on top of it.

Customer-managed keys for your crown jewels

For the most sensitive data an institution holds, there is one more tier of control, and it comes with an honest tradeoff that you should understand before you reach for it.

Double Key Encryption protects data with two keys: one your institution controls, and one stored securely in Microsoft Azure. Both keys are required to view the data, so Microsoft can access only one key and the content stays unavailable to Microsoft alone. Microsoft documents Double Key Encryption as a control that helps meet regulatory requirements including the Gramm-Leach-Bliley Act, and positions it for highly regulated industries such as financial services.

The tradeoff is real and you should not be sold this control without it. Because the Microsoft 365 service cannot decrypt Double Key Encryption content on its own, that content cannot be processed by the cloud services that need to read it. Per Microsoft's own documentation, that list includes Microsoft 365 Copilot, eDiscovery content inspection, content search and indexing, coauthoring in the Office web apps, and mail-flow rules that scan attachments. Double Key Encryption also requires Microsoft 365 E5, or equivalent Purview Information Protection licensing.

This is precisely where experienced configuration earns its keep. Applying Double Key Encryption to everything would cripple search, eDiscovery, and Copilot across your whole tenant. Applying it to nothing leaves your most sensitive data with the same protection as a routine memo. The work is identifying which data belongs in which tier, applying the right control to each, and documenting the decision so an examiner sees deliberate data classification rather than a blanket setting or an oversight.

The encryption mandate reaches credit unions, banks, and mortgage companies through two regulatory doors, and the same Microsoft 365 controls answer both.

The encouraging part of all this is how little of it requires a purchase order. The controls that close the gap are, for most institutions, already paid for.

Encryption is one layer of a defensible Microsoft 365 program. The identity layer that keeps attackers from authenticating in the first place matters just as much, which is why our guide on phishing-resistant multifactor authentication for financial institutions is a natural next read. And because encryption protects data you still have to be able to recover, pair it with the approach in our guide on Microsoft 365 backup for financial institutions. For banks specifically navigating GLBA and OCC expectations, our deeper guide on Microsoft 365, GLBA, and OCC compliance for community banks ties the encryption control into the broader examination picture.

Frequently Asked Questions