In This Article
Click a colleague's name in Microsoft 365 today and you get a profile card: their photo, their title, their department, a button to start a chat. In late August, that card starts telling you considerably more. Their division. Their role. Their employee number. The cost center they bill to. The street address on file. And the exact name they use to sign in.
Microsoft published Message Center message MC1438571 on July 24 and tagged it as a major change. Eleven profile card properties that are hidden today, and that an administrator has to deliberately switch on, become visible by default whenever they contain data. The rollout covers Worldwide, GCC, GCC High, and DoD tenants, which means regulated environments are not being staged away from it.
For most organizations this is a small convenience upgrade. For a bank, a credit union, or a mortgage company, two of those eleven fields deserve a decision rather than a shrug, and the window to make that decision closes when the rollout lands. We manage the Microsoft 365 tenants of more than 750 banks, credit unions, and mortgage companies, so here is the read we are giving them.
What Microsoft is changing
Profile cards in Microsoft 365 already show a set of properties that administrators cannot turn off: name, email, chat, work phone, mobile, work location, company, job title, department, and business address. That baseline is not moving.
Sitting underneath it is a second set that Microsoft calls optional properties, and Microsoft's public admin documentation lists all eleven of them. Today they are hidden, and an administrator has to enable each one before anyone sees it. MC1438571 reverses that default. From late August, each of these displays automatically wherever the underlying field has a value.
One practical note on checking this yourself. Message Center posts are visible only inside your own tenant, so MC1438571 is not something you can look up on the open web. If you want to confirm the rollout notice directly, open the Microsoft 365 admin center, go to Health, then Message center, and search the message ID. The property list itself, and the admin paths for changing visibility, are public in Microsoft Learn.
| Property | What it exposes once visible | Review priority |
|---|---|---|
| User principal name | The identifier the user signs in to Microsoft 365 with | Highest |
| Employee number | The internal staff identifier used across HR and core systems | Highest |
| Street address, State, Postal code | Location detail, rendered under the business address attribute | High if any record holds a home address |
| Cost center | Which budget line the person belongs to | Medium |
| Division, Role, Employee type | Where the person sits in the org and whether they are staff, contract, or temporary | Medium |
| Alias | The mail nickname behind the mailbox | Low |
| Fax | Fax number where one is on file | Low |
Two details in Microsoft's documentation shape how you should read that table. Street address, state, and postal code do not appear as separate lines; they render under the existing business address attribute. And these properties are visible both to a person looking at their own profile and to anyone in the tenant looking at theirs.
Where the values come from matters too. Microsoft documents four sources for profile card data: Microsoft Entra ID, organizational data in Microsoft 365, Microsoft 365 Copilot connectors for people data, and details users enter themselves. A tenant that has synced a full HR record into Entra ID has considerably more of these fields populated than one that has not, and populated is the trigger for display.
Why a directory change is a security question
Start with the user principal name, because it carries the most weight. In Microsoft 365 the UPN is the sign-in identifier. Publishing it on the profile card means every account in the tenant can read a confirmed, current list of valid usernames, formatted exactly as the sign-in page expects them.
That is the input a password spray campaign needs. Spraying is cheap when the username list is right and expensive when it is guesswork, and a directory that hands over the correct format removes the guesswork. We have written about where these attacks slip past tenants that believe they are covered in our breakdown of the Conditional Access password spray gap in Microsoft 365.
A password spray campaign is only as good as its username list. A directory that publishes sign-in names by default writes that list for the attacker.
There is a fair objection to raise here, and it is worth answering directly. Profile cards are not public. Reading one means being signed in to your tenant, so an attacker who can see this data already has an account. True, and that is the point rather than the rebuttal. The first foothold in most identity attacks is a single ordinary employee, often one with no privileged access and nothing worth stealing in their own mailbox. What that one account can see is what decides how far the second stage reaches, and after this change it can see the sign-in name of everyone else in the building.
Why This Matters for Financial Institutions
The exposure here is directory data, not a vulnerability. Nothing is being breached, and there is no patch to apply. That is exactly what makes this class of change easy to miss: it arrives as a Message Center post rather than an alert, and it takes effect whether or not anyone reads it.
What separates a bank from a general business on this one is the value of a validated staff list. Sign-in names, employee identifiers, and role detail are the raw material for the two attack patterns that hit financial institutions hardest, credential attacks against the identity plane and social engineering against people who can move money.
The second problem is quieter and harder to fix with a policy. Employee number, employee type, cost center, division, and role are the details that make a pretext sound like it came from inside the building. An attacker who can name your division, cite your employee number, and know that you are a contractor rather than a staff member is running a materially more convincing script than one working from a LinkedIn page.
Microsoft's own Q2 2026 data makes the point by contrast. Across its global telemetry, 52% of the Microsoft Teams phishing it observed in June used a generic display name rather than impersonating IT at all. More than half of it already works without any insider detail. Directory data raises that floor.
That lands differently in July 2026 than it would have two years ago, because of where social engineering is actually arriving. Microsoft's Q2 2026 email threat landscape report, published the day before this Message Center post, recorded weekly malicious Microsoft Teams call attempts running at nearly ten times their mid-2025 baseline, with vishing attempts up 31% from April to May and another 27% into June. Microsoft detected roughly 7.6 billion email-based phishing threats over the same quarter.
Those two facts belong in the same sentence. Voice-based social engineering inside Teams is climbing sharply, and a richer directory gives the caller better material to work with. Our analysis of what Microsoft's Q2 2026 threat data means for financial institutions covers that channel shift in full.
None of this makes the profile card change reckless on Microsoft's part. Filling in the org chart is a real productivity gain, and most of the eleven properties are harmless in most tenants. The point is narrower: a default that suits a software company does not automatically suit an institution whose staff authorize wires.
What hiding a property actually does
This is where a lot of quick guidance on this change will get it wrong, so it is worth being precise.
Hiding a property removes it from the profile card. Microsoft's documentation is explicit that hiding does not delete the underlying data from Microsoft 365 profiles, and does not stop that property from appearing in other Microsoft 365 experiences. To remove the data itself, you have to remove it from the source system it was populated from.
Hiding is a display control, not a data control
What it does. It takes the property off the profile card, for everyone in the tenant. Microsoft notes that a visibility change can take up to 24 hours to be reflected.
What it does not do. It does not delete the value from the Microsoft 365 profile, it does not remove it from the source system, and Microsoft states plainly that it does not stop the property from appearing in other Microsoft 365 experiences. Permanently removing the data means removing it where it came from.
Why the distinction matters. If your answer to an examiner is that staff location data is protected because you hid it on the profile card, that answer will not survive follow-up. Hiding reduces casual exposure to everyone in the tenant. It is not a data governance control, and it should not be recorded as one.
That distinction changes what a good response looks like. The question is not simply which fields to hide. It is which fields should have been populated in the first place, and whether the data flowing into Entra ID from your HR system belongs in a directory every account in the tenant can read. That second question is a data-hygiene project rather than a settings change, and it is the part we take on for the tenants we manage.
For most institutions the honest answer on street address is that nobody ever decided. The field filled itself when HR sync was configured, it stayed invisible because the default hid it, and nobody has had a reason to look at it since. That is the same shape of problem we walk through in our guide to fixing data exposure before turning on Microsoft 365 Copilot, where content nobody deliberately shared becomes visible the moment a new surface starts reading it.
How to decide before late August
There are two control paths, and the one you use depends on whether you act before or after the rollout.
The pre-rollout path runs through the Microsoft Graph profile card API, which Microsoft documents publicly. The post-rollout path is in the admin center under Settings, then Org settings, then People settings, then Profile card, then Contact info. Either way you need a Global Administrator or a People Administrator, and delegated calls to the API require a tenant administrator role.
Profile card visibility is configured through the Microsoft Graph profile card property resource under the admin people endpoint, sending the directory property name together with a visibility flag. Reading the current configuration requires the PeopleSettings.Read.All permission and changing it requires PeopleSettings.ReadWrite.All. The Microsoft Graph PowerShell module carries the same operations as the AdminPeopleProfileCardProperty cmdlets from module version 1.24.0 forward, which is the practical way to audit every property at once rather than clicking through them. The API is available in the global service and in the US Government L4 and L5 environments, which is the practical reason regulated tenants cannot treat this rollout as something that will pass them by.
Our recommendation for banks, credit unions, and mortgage companies is not to hide all eleven. Blanket suppression throws away a genuine productivity gain, and division and role are useful to staff trying to find the right person quickly. The decision that pays for itself is narrower.
- Suppress user principal name. There is no workflow inside a financial institution that needs every employee to read every other employee's sign-in identifier from a profile card. The productivity value is close to zero and the attacker value is high.
- Suppress employee number. Internal staff identifiers get used as verification tokens by help desks and phone systems more often than anyone documents. Publishing them tenant-wide quietly weakens whatever process depends on them.
- Audit street address before deciding. Query what is actually in the field. If any record holds a home address rather than a branch address, suppress it and fix the source data. If every value is a branch, the field is harmless.
- Let division, role, and employee type through unless you have a reason. These are the ones with real findability value, and they are the reason Microsoft is making the change.
- Record the decision. Whichever way you go on each property, write down that you chose it. A deliberate configuration you can explain is worth more at exam time than a defensible default you never reviewed.
What we do for the tenants we manage
As a Tier-1 Microsoft Cloud Solution Provider, we manage the Microsoft 365 tenants of more than 750 banks, credit unions, and mortgage companies. Delegated administration is what makes a change like this operational rather than advisory: we can read the current profile card configuration across the tenants we manage, and we can change it, instead of sending a customer a link and hoping someone gets to it before late August.
Tenant default drift is the category this belongs to, and it is a steady part of the work. Microsoft ships changes constantly, most of them are fine, and a small number quietly widen what a tenant exposes. The Microsoft Teams AI meeting archive change had the same shape: a sensible default for most customers, a decision worth making deliberately in a regulated one.
Every Message Center item that changes a default gets read, classified, and turned into a yes-or-no decision for the tenants we manage, which is why a change like this one reaches our customers as a recommendation rather than as a surprise in September.
For customers on M365 Guardian, our managed Microsoft 365 security service, this specific change runs as four steps:
- Inventory before the deadline. Read the current profile card property configuration in each managed tenant and check which of the eleven fields hold values, so the decision is made against real data rather than a hypothetical.
- Set visibility ahead of the rollout. Apply the suppression decisions through Microsoft Graph before late August, so the new default never takes effect on the fields that matter, and verify the configuration reads back correctly afterward.
- Trace the source data. Where a field holds something it should not, such as a home address synced from an HR record, fix it at the source system rather than only hiding the display. Hiding is the fast control; the source fix is the durable one.
- Respond on the identity plane, not just watch it. Guardian MxDR brings Microsoft Entra ID and Microsoft Defender signals into one place, and monitoring is only half the job. The moment Entra ID raises a risky sign-in on an account, our zero-tolerance threat response fires against the Microsoft Graph API and kills that account's active sessions, so stolen refresh tokens stop working on every device at once, with continuous access evaluation forcing a fresh access decision rather than letting an old one ride until it expires. Nobody has to be watching a queue for that to happen. Here is why it matters on this specific change: if publishing sign-in names makes a spray attempt cheaper to run, a correct guess still has to survive the seconds after it trips risk detection, and it does not.
Microsoft Purview data loss prevention policies are the layer underneath that, governing where staff and customer detail can travel once it exists. These are Microsoft controls, not proprietary magic, and that is the point: they only work if someone owns keeping them set correctly while the platform moves underneath them. That ownership is the job.
The operational takeaway
This is not an emergency and it does not need a project. It needs one administrator, roughly an hour, and a decision recorded on each of the eleven properties before late August. The institutions that get caught by this will not be the ones that decided to publish sign-in names. They will be the ones that never read the message.
Do you know which of the eleven properties are populated in your tenant right now?
We manage Microsoft 365 tenants for more than 750 banks, credit unions, and mortgage companies, and we are reading profile card configuration across those tenants before the rollout lands. We will run the same read on yours and tell you exactly which of the eleven fields hold data, what they would expose, and which ones we would suppress before late August.
What examiners will ask about this
No examiner is going to arrive with MC1438571 printed out. The questions that actually land are about whether you have a process for platform changes at all, and this rollout is a clean test case for it.
- If staff identifiers are used to verify callers to the help desk, does your verification process still hold when those identifiers are readable by everyone in the tenant?
- Can you show a deliberate decision on what your staff directory exposes, rather than whatever the platform defaulted to?
- Do you monitor vendor change notifications, and can you name a change you acted on before it took effect?
- Do you know which personal data fields are synced into Microsoft Entra ID from your HR system, and who decided that?
That first question is the one worth carrying into your next process review. Verification schemes tend to quietly depend on a detail being hard to look up, and this change makes one of those details easy to look up. The same reasoning applies to the internal misuse case, which our guide to insider risk management for financial institutions covers in more depth.
If you would rather know where your own tenant stands before someone else asks, talk to us and we will walk the configuration with you.
Frequently Asked Questions
Microsoft 365 Message Center message MC1438571, published July 24, 2026 and flagged as a major change, states that eleven optional profile card properties change from disabled by default to displayed by default when they contain data. The eleven are division, role, employee number, employee type, cost center, user principal name, alias, fax, street address, state, and postal code. Today an administrator has to enable each one manually. After the change, each displays automatically wherever the underlying field holds a value.
Microsoft states that general availability begins in late August 2026 and is expected to complete in late August 2026. The rollout covers Worldwide, GCC, GCC High, and DoD environments, so regulated and government tenants are included rather than staged separately. Microsoft has not published a specific calendar date within that window, so treat late August as the deadline for any configuration you want in place beforehand.
The user principal name is the identifier a person signs in to Microsoft 365 with. Showing it on the profile card by default means every account in the tenant can read a confirmed and current list of valid usernames in exactly the format the sign-in page expects. That is the input a password spray campaign needs, and it removes the guesswork that normally makes spraying expensive. Suppressing this single property is the highest value item on the list for most financial institutions, because the productivity benefit of showing it is close to zero.
Before the rollout, visibility is set through the Microsoft Graph profile card property API under the admin people endpoint, sending each directory property name together with a visibility flag set to false. Reading the configuration requires the PeopleSettings.Read.All permission and writing it requires PeopleSettings.ReadWrite.All, and delegated calls require a tenant administrator role. The equivalent Microsoft Graph PowerShell cmdlets are available from module version 1.24.0 forward. After the rollout, visibility can be managed in the Microsoft 365 admin center under Settings, then Org settings, then People settings, then Profile card, then Contact info, by a Global Administrator or People Administrator. Changes take up to 24 hours to appear.
No. Microsoft's documentation states that hiding a property removes it from profile cards but does not delete the underlying data from Microsoft 365 profiles, and does not stop the property from appearing in other Microsoft 365 experiences. Permanently removing the data requires removing it from the source system that populated it, such as the HR system feeding Microsoft Entra ID. Treat hiding as a control on casual visibility rather than as a data governance measure, and do not record it as one in a compliance response.
Blanket suppression is usually the wrong answer. Division, role, and employee type carry real value for staff trying to find the right colleague, which is why Microsoft is making the change. The properties worth suppressing in most financial institutions are user principal name and employee number, because both are useful to an attacker and neither helps an employee do their job. Street address deserves an audit first: if any record holds a home address rather than a branch address, suppress it and correct the source data. Whichever way you decide on each property, record the decision so it reads as deliberate configuration rather than an unreviewed default.
