What the new Microsoft security initiate around MFA and Phishing will means for your business
For years, one of the most common pieces of cybersecurity advice was simple:
Turn on multifactor authentication.
And it was good advice.
A password by itself is fragile. It can be guessed, reused, stolen in a breach, captured through phishing or simply handed to an attacker by someone who thought they were logging into Microsoft 365.
MFA added another barrier.
Even if someone had your password, they still needed something else.
A text message. A six-digit code. A push notification. A phone call.
That made account compromise considerably harder.
The problem is that attackers adapted.
Today, the question is no longer simply:
Do you have MFA?
The better question is:
What kind of MFA do you have?
Because not all MFA provides the same protection, and some of the authentication methods businesses have relied on for years can still be phished.
Microsoft is now making that distinction very clear.
Microsoft Says Traditional MFA Is No Longer Enough
Microsoft's current security guidance is unusually direct:
“Traditional MFA is no longer enough. Phishing-resistant MFA is the new baseline.”
That's a significant statement.
Microsoft is no longer treating every second factor as though it provides equivalent protection.
A text message, an approval notification and a cryptographically protected passkey may all add another step to authentication.
They do not provide the same security.
Modern attackers can use social engineering, adversary-in-the-middle techniques and MFA fatigue to work around traditional authentication methods. Microsoft's own Secure Future Initiative is moving toward phishing-resistant authentication using technologies including passkeys, FIDO2 security keys and Windows Hello for Business, backed by Conditional Access enforcement.
And this isn't just another recommendation buried in a security white paper.
Microsoft has already started changing Entra.
The Change Started September 1, 2026
As of September 1, 2026, Microsoft began making passkeys the default authentication experience for users enabled for SMS or voice.
Those users are automatically enabled for passkeys in the Entra Authentication Methods Policy and brought into Microsoft's passkey registration campaign. When they sign in and complete MFA, Microsoft can begin prompting them to register a passkey.
In other words:
This transition has already started.
And Makios is using that transition as the starting point for something broader:
Basic Security will become the minimum security specification for every account we manage going forward.
We have already started rolling these protections out across legacy accounts and environments, and that work will continue throughout Q4 2026.
The objective is straightforward.
Accounts that were configured years ago under older security standards should not remain there indefinitely simply because they still work.
As Microsoft moves its identity platform toward phishing-resistant authentication, we are using that same transition to bring every managed account toward a consistent minimum security baseline.
This is not an optional premium security tier.
It is becoming the minimum standard required for Makios to responsibly manage an account.
And Microsoft Isn't Stopping There
The next major date is February 1, 2027.
Beginning then, Microsoft-provided SMS and voice authentication will be retired for most Microsoft Entra users.
Users whose only available MFA method is SMS or voice will be required to register a passkey before they can continue signing in. Microsoft says that prompt will be blocking, and there is no opt-out from the February 1 enforcement for users in scope.
Global Administrators and external users follow a later Microsoft-provided SMS and voice retirement date of July 1, 2027. Internal guest users remain on the February 1 schedule.
Organizations with a legitimate business, regulatory or operational requirement to keep SMS or voice will have the option of using a supported customer-managed telephony provider.
But that's an important distinction.
Microsoft isn't saying SMS becomes secure if somebody else delivers the message.
Microsoft says the primary reason for retiring its own SMS and voice delivery is security, describing those methods as among the most vulnerable authentication options available today and as providing significantly weaker protection against phishing and account compromise than passkeys.
The direction is hard to miss.
Microsoft is moving authentication toward phishing-resistant methods.
So are we.
What Does Phishing-Resistant Actually Mean?
Let's make this practical.
Suppose you receive an email telling you that your Microsoft 365 password is about to expire.
You click the link.
The page looks exactly like Microsoft.
Logo.
Colors.
Fonts.
Everything.
You enter your email address and password.
Microsoft asks for MFA.
So does the fake site.
You receive a six-digit code and type it in.
Or perhaps you receive an authentication request and approve it.
Unfortunately, an attacker may be sitting between you and Microsoft's real authentication service.
Your password gets relayed.
Your second factor gets relayed.
And depending on the attack, the attacker may obtain an authenticated session.
You had MFA.
You still got phished.
That's one of the problems phishing-resistant authentication is designed to solve.
Phishing-Resistant Authentication Changes the Architecture
Passkeys and FIDO2 credentials work differently.
Instead of giving the user another secret to type into a website, authentication uses public-key cryptography.
The private credential stays associated with the user's device or authenticator.
More importantly, the authentication credential is cryptographically associated with the legitimate service.
If someone builds a convincing fake Microsoft login page, there isn't simply another six-digit code sitting there waiting for an employee to hand over.
The fraudulent website is the wrong destination.
The credential won't authenticate it.
That's a fundamentally different security model.
Instead of relying entirely on someone noticing that a login page looks suspicious, the authentication technology itself helps prevent the credential from being used against the wrong service.
That's what we mean by phishing-resistant authentication.
What Should Businesses Be Moving Toward?
For organizations using Microsoft 365 and Entra ID, there are several important options.
Passkeys
Passkeys use public-key authentication rather than reusable secrets that can easily be captured and replayed.
There is no traditional MFA code for someone to accidentally type into a phishing page.
Microsoft is now making passkeys central to its transition away from Microsoft-provided SMS and voice authentication.
Windows Hello for Business
Windows Hello for Business is particularly useful for companies with managed Windows computers.
When someone uses their face, fingerprint or PIN to authenticate on a properly configured device, the important part isn't really the biometric.
The biometric or PIN unlocks a cryptographic credential associated with the device.
Your PIN isn't simply another password being transmitted to Microsoft.
Microsoft identifies Windows Hello for Business as one of the phishing-resistant methods organizations can use as part of this transition.
For organizations already standardizing around Microsoft 365, Entra ID, Intune and Windows, it can provide strong authentication without making every employee carry another device around all day.
FIDO2 Security Keys
Physical FIDO2 security keys provide another phishing-resistant option.
These can be particularly useful for administrators, executives, shared workstation scenarios or other higher-risk situations.
The user possesses the physical credential and typically unlocks it with a PIN or biometric.
Again, there is no temporary six-digit authentication code waiting to be handed to an attacker.
Microsoft includes FIDO2 security keys in its phishing-resistant authentication strategy.
What About Microsoft Authenticator?
This is where terminology can get confusing.
Having Microsoft Authenticator installed does not automatically mean you're using phishing-resistant authentication.
Authenticator can be involved in different authentication experiences.
Traditional approval workflows and a passkey are not the same authentication method.
So the question isn't:
“Do we have Microsoft Authenticator?”
It's:
“Which authentication method are we actually using?”
Small distinction.
Big difference.
And What About SMS?
SMS served an important purpose.
It helped move millions of accounts away from password-only authentication.
That was progress.
But SMS should no longer be considered the destination for business security.
A text message contains a code that a human can read.
Which means a human can also type it into the wrong website.
That's the fundamental problem.
The code isn't inherently bound to Microsoft's legitimate authentication service.
Someone can potentially trick you into giving it to them.
There are other risks as well, including social engineering around phone numbers and SIM-related attacks.
Microsoft now says SMS and voice are among the most vulnerable authentication methods available and offer significantly weaker protection against phishing and account compromise than passkeys.
So when Microsoft retires its own SMS and voice delivery in 2027, this isn't merely another Microsoft product change.
It reflects a larger shift in how identity security is being designed.
“Require MFA” and “Require Phishing-Resistant MFA” Are Not the Same Thing
This is one of the most important concepts for business owners to understand.
An account protected by a password and SMS code technically has MFA.
An account protected using a phishing-resistant credential also has MFA.
That does not mean they have the same protection.
The entire point of Microsoft's move is that authentication methods need to be judged by their resistance to modern attacks, not simply by whether they satisfy the old definition of “something else after the password.”
That's why simply looking at a dashboard and seeing:
MFA: Enabled
isn't enough anymore.
We need to know how the person is actually authenticating.
The Weakest Method Can Still Become the Problem
Suppose we configure Windows Hello for Business perfectly.
An employee uses phishing-resistant authentication every morning.
Great.
But perhaps the account still has an unnecessarily weak authentication or recovery path available.
An attacker doesn't care which method we prefer.
They care which method they can exploit.
The same applies to account recovery.
You can build a very strong front door and accidentally leave a weaker side door through recovery procedures, legacy authentication or poorly controlled enrollment.
Authentication therefore has to be treated as a system.
Businesses should understand:
- Which authentication methods are enabled
- Which methods employees actually use
- Which methods are allowed as fallbacks
- How new authentication methods are enrolled
- How lost credentials are recovered
- How administrator and privileged accounts are protected
- Which legacy authentication methods remain enabled
- Whether the environment actually enforces the intended authentication standard
That's a much better security conversation than simply asking whether MFA is turned on.
This Doesn't Mean We Flip Every Switch Tomorrow
Security changes need to be operationally sane.
People lose phones.
Computers break.
New employees need accounts.
Executives travel.
Remote workers replace devices.
Administrators need emergency access.
And sometimes old applications don't cooperate.
Moving to phishing-resistant authentication therefore needs to be planned.
Microsoft's own deployment guidance recommends evaluating device readiness before enforcing phishing-resistant passwordless authentication.
So we're not advocating disabling everything on Friday afternoon and seeing who can still log in Monday morning.
That's not a migration strategy.
That's entertainment.
The transition should be deliberate.
The destination, however, is becoming much clearer.
Humans Are Still Important. They Just Shouldn't Be the Security Boundary.
Employees should absolutely receive cybersecurity awareness training.
They should recognize suspicious emails.
They should question strange requests.
They should report something that doesn't look right.
But there's a limit to how much cybersecurity we should expect someone to provide by staring at URLs.
A good phishing attack is specifically designed to fool someone.
The email might look right.
The domain might look close.
The login page may look identical.
And AI is making believable phishing, impersonation and social engineering easier to create at scale.
Telling employees to simply “be more careful” isn't a cybersecurity architecture.
Where technology can remove the decision entirely, it should.
A phishing-resistant credential doesn't need to notice that the Microsoft login page looks slightly strange.
It doesn't get distracted.
It doesn't have 47 emails waiting.
It doesn't click something because it's late for a meeting.
The credential simply knows:
This isn't the service I belong to.
And it doesn't authenticate.
That's exactly what we want.
Makios Is Changing Our Standard Too
Our authentication standard going forward is straightforward:
Phishing-resistant authentication is required. Passkeys, Windows Hello for Business or FIDO2 are preferred. SMS and voice authentication are not approved as primary MFA methods.
That doesn't mean every account changes on exactly the same day.
There will be migration periods.
There will be technical exceptions.
There will be legacy systems.
There will occasionally be a legitimate reason why a preferred authentication method can't be implemented immediately.
We can work through those.
What we're no longer willing to do is treat weak authentication as a permanent design choice simply because that's how an account was configured years ago.
And importantly:
We're not waiting until February 2027.
The Microsoft transition started September 1.
Our Basic Security rollout has started too.
We have already begun updating legacy accounts and environments and will continue that work throughout Q4 2026.
The objective isn't to make everyone's technology newer for the sake of making it newer.
It is to establish a reasonable minimum security specification across every account Makios is responsible for managing.
We're Also Addressing Legacy Accounts
Makios manages environments that have existed for many years.
Some were originally built under different Microsoft licensing.
Different security capabilities.
Different threat models.
And frankly, different expectations of what constituted reasonable cybersecurity.
There are accounts and environments out there today that may still technically work but are configured in ways we would never approve for a new deployment.
Historically, the IT industry's approach to that problem has often been:
Recommend the improvement.
Client declines.
Document the decision.
Move on.
There are some risks where we're no longer comfortable doing that.
Makios will progressively enable our Basic Security baseline across the legacy accounts and environments we manage.
Authentication is an important part of that baseline.
If we identify accounts that are unnecessarily exposed because of outdated authentication practices, we're going to work toward correcting them.
Not because we want another project.
Not because we need another product to sell.
Because leaving known, breach-prone configurations in production indefinitely is becoming increasingly difficult to justify.
There Is a Difference Between “Not Yet” and “No”
We understand that security changes have operational consequences.
A client may need time.
We may need to test an application.
Employees may need to register credentials.
Hardware may need to be updated.
There may be a legitimate technical limitation we need to solve first.
That's normal.
There is an important difference between:
“We need some time to get there.”
and
“We don't want these protections.”
We can work with the first.
We're no longer willing to indefinitely support the second.
Basic Security Isn't an Optional Upgrade
There are security controls that are optional.
There are products that can be evaluated based on cost, risk and business requirements.
And there are controls that eventually become part of the minimum level of care required to responsibly operate an environment.
We believe authentication is crossing that line.
A compromised Microsoft 365 account can expose far more than someone's inbox.
It can expose company files.
Customer information.
Financial information.
Internal conversations.
It can allow an attacker to impersonate an executive.
Request fraudulent payments.
Attack employees.
Attack vendors.
Attack customers.
And when Makios manages that environment, we're involved in what happens next.
Our team investigates it.
Our team contains it.
Our team helps recover it.
Our administrative access may be involved.
Our systems may be involved.
Our reputation is involved.
And other organizations that trust communications coming from that account may be involved.
At some point, accepting a known and avoidable security weakness stops being only the customer's risk.
It becomes ours too.
Sometimes We're Just Not the Right Fit
We don't expect every organization to have the newest technology.
We don't expect clients to spend unlimited amounts of money chasing theoretical security risks.
And we don't expect every security change to happen immediately.
Security has to remain practical.
But there has to be a floor.
Microsoft is raising that floor.
So are we.
If a client needs time to transition, we'll help build the path.
If there is a legitimate technical limitation, we'll work through it.
If a change needs to be staged carefully to protect operations, that's exactly what we'll do.
But if an organization fundamentally wants to continue operating below what Makios considers a reasonable Basic Security standard, even when a practical solution exists, then we may simply no longer be the right IT provider for that organization.
That's not meant as a threat.
It's a question of fit.
There are providers willing to manage environments with weaker controls and accept those risks.
Makios is increasingly not one of them.
We can't tell clients we're responsible for helping secure their technology while knowingly maintaining configurations we believe are unnecessarily breach-prone.
Those two positions don't fit together.
If an organization fundamentally disagrees with the minimum security controls Makios believes are necessary to responsibly manage its environment, we'll help facilitate an orderly transition to another provider.
No hostility.
No scare tactics.
We're just probably not a good fit anymore.
The Bottom Line:
For years, businesses asked:
Do we have MFA enabled?
That's no longer the right question.
Is our authentication actually resistant to phishing?
Microsoft has already started changing the answer.
As of September 1, 2026, Microsoft began automatically enabling passkeys for users enabled for SMS or voice and bringing those users into its passkey registration experience.
Beginning February 1, 2027, Microsoft-provided SMS and voice authentication will be retired for most Entra users. Users relying exclusively on those methods who have not moved to another supported option will face a blocking requirement to register a passkey before continuing to sign in.
Microsoft's own security guidance puts the direction plainly:
Phishing-resistant MFA is the new baseline.
Makios is using that transition to establish our own baseline too.
Basic Security will become the minimum security specification for every account we manage going forward.
We've already started rolling it out across legacy accounts and environments, and that work will continue throughout Q4 2026.
We'll do it carefully.
We'll help clients through the transition.
We'll account for legitimate technical limitations.
But intentionally remaining below a reasonable minimum security baseline is no longer a risk we're willing to accept indefinitely.
Microsoft is moving. Attackers already moved. It's time for the security baseline to move too.
