Trusted Device and Phishing-Resistant Access
Most small-business Microsoft 365 breaches start with a phished password and a relayed MFA prompt — and you do not need Microsoft Intune to shut both doors. IT Partner restricts Microsoft 365 access to your approved, Microsoft Entra joined Windows PCs with Conditional Access, blocks legacy authentication, adds phishing-resistant sign-in (passkeys and FIDO2 security keys, Windows Hello for Business, or certificate-based authentication) so relayed credentials stop working, and enforces a documented mobile-access model — Blocked or Restricted, your choice. Every policy runs in report-only mode with test sign-ins before anything is enforced, and emergency access accounts are validated first. Scoped and quoted in writing; you pay after you approve delivery.
What this engagement is
A modern Microsoft 365 break-in rarely looks like hacking. The attacker phishes a password, relays the MFA prompt through a look-alike sign-in page — an adversary-in-the-middle kit does this automatically — and then connects from their own computer with a perfectly valid session. Every control that only checks who is signing in has already been satisfied. This service adds the two checks that were missing: which device the sign-in comes from, and whether the credential can be relayed at all. IT Partner configures a lightweight access-control baseline for organizations that cannot — or do not want to — deploy Microsoft Intune. Approved Windows PCs are joined to Microsoft Entra ID (or Microsoft Entra hybrid joined where on-premises Active Directory remains), and a Conditional Access policy using a device filter on the join state blocks covered Microsoft 365 access from every Windows device that is not one of them; this works on device identity alone, with no compliance platform behind it. Legacy authentication, which bypasses Conditional Access entirely, is blocked. Phishing-resistant authentication is then enforced for the users and scenarios you select through a Conditional Access authentication-strength policy: Microsoft's built-in phishing-resistant strength accepts Windows Hello for Business, passkeys (FIDO2) — hardware security keys or device-bound passkeys in Microsoft Authenticator — and certificate-based authentication, and we choose with you which of those your people can realistically register before anything is required. Mobile access is decided deliberately, not by accident: Blocked Mobile Access is the clearest Intune-free boundary; Restricted Mobile Access keeps an agreed level of phone access with the protections that exist. Anti-phishing, Safe Links and Safe Attachments, impersonation protection, and external-sender tagging are configured where your existing licenses provide them. Microsoft has set the direction here — passkeys are becoming the default registration path in Microsoft Entra ID from September 2026, Microsoft-provided SMS and voice MFA is scheduled for retirement in February 2027, and multifactor authentication is already mandatory for Azure's administrative portals and command-line tools — so the question is whether the move happens on your schedule or a forced one; confirm dates against Microsoft's current announcements, which shift. What this is not matters just as much. It establishes identity-based and device-identity-based access control; it is not endpoint management. It does not provide device compliance, mobile application management, or continuous validation of device health, and it never pretends to — where a control has limits, the configuration summary says so in writing. When you outgrow the baseline, it converts cleanly: the device identities and policies it creates are the foundation an Intune deployment builds on, and managed Intune can carry it from there. If you already run Intune, the Conditional Access implementation with compliance-based policies is the better fit; if you want Windows Hello for Business rolled out through Intune profiles, that is our passwordless authentication service; and if your users are not yet on MFA at all, Enable MFA for All Users comes first.
Success criteria
What you receive
How the work unfolds
Review the tenant, the Microsoft licenses available to each covered user, identity configuration, supported device platforms, existing Conditional Access policies, and current authentication-method registration. Confirm the join model and the mobile-access mode. Access is time-bound and least-privilege, approved by you.
Create or validate emergency access accounts, exclude them from every policy that could otherwise lock administrators out, and record the recovery procedure before any policy is created.
Define the approved Windows device state, restrict who can join devices where the platform supports it, and document the procedure for approving, joining, verifying, disabling, and removing devices.
Configure a report-only Conditional Access policy that blocks covered Microsoft 365 access from Windows devices that do not meet the selected Microsoft Entra join-state requirement, and review its report-only results against real sign-in traffic.
Block legacy authentication. Enable the selected phishing-resistant method in the authentication-methods policy, guide registration for the selected users, and configure the authentication-strength policy in report-only mode until registration is confirmed.
Implement either complete mobile blocking or the documented Restricted Mobile Access model for iOS and Android, using the Conditional Access and Microsoft 365 controls available without Intune.
Configure or review the Microsoft 365 email security controls available under your licenses — anti-phishing, link and attachment protection, impersonation protection, and external-sender identification.
Test approved and blocked sign-in scenarios on representative Windows, iOS, and Android devices, review report-only results, document exceptions for your approval, enable the agreed policies in production, and hand over the configuration summary.
Prerequisites
Who does what
IT Partner
- Review the existing tenant configuration and identify conflicts with the proposed access model.
- Design and configure the Conditional Access, authentication-method, and authentication-strength policies included in scope.
- Configure or validate emergency access accounts and their exclusions, and test them after enforcement.
- Provide the approved Windows device onboarding procedure.
- Configure the selected mobile-access mode.
- Configure or review the included email threat protection settings available under your licenses.
- Perform the agreed pilot testing and document observed policy results and exceptions.
- Provide the final configuration summary, including known limitations and recovery steps.
Your team
- Provide the required licenses and time-bound administrative access.
- Identify approved users, devices, administrators, service accounts, and exceptions.
- Choose the mobile-access mode and the phishing-resistant method before implementation.
- Make supported Windows devices available for joining and testing, and supply FIDO2 security keys if that method is chosen.
- Notify affected users of sign-in, authentication-registration, and mobile-access changes.
- Approve pilot results and documented exceptions before enforcement.
- Maintain an internal process for approving new devices and removing lost, replaced, or retired devices.
- Respond to account compromise, device loss, and security alerts after the implementation is complete.
What's not included
Limitations & technical notes
Frequently asked questions
Does this service require Microsoft Intune?
No — that is the point of it. The service is designed for organizations that cannot or do not want to deploy Microsoft Intune. It uses Microsoft Entra device identity, Conditional Access device filters, authentication strengths, and the Microsoft 365 email security features already in your licenses. When you later outgrow this baseline, it converts cleanly: the device identities and policies it creates are the same foundation an Intune deployment builds on.
Which phishing-resistant sign-in methods do you configure?
The ones Microsoft Entra's built-in phishing-resistant authentication strength accepts: Windows Hello for Business on joined PCs, passkeys (FIDO2) — either hardware security keys or device-bound passkeys in Microsoft Authenticator — and certificate-based authentication where you already run a PKI. We pick with you based on what your users can realistically register: a five-person finance team can carry security keys; a field workforce is usually better served by Authenticator passkeys. Registration happens before the policy is enforced, never the other way round.
Will this stop an attacker who has stolen a user's password and MFA approval?
It is built to. The trusted-device policy blocks covered Microsoft 365 access from the attacker's unknown Windows computer, and phishing-resistant authentication makes credentials relayed through a phishing site useless because the credential is bound to the legitimate site and device. No control stops everything — token theft from an approved device, malware, remote-control fraud, consent phishing, and help-desk social engineering remain possible — and the configuration summary states those residual risks plainly.
Does an approved Windows PC need to be Microsoft Entra joined?
Yes — for cloud-managed Windows environments the intended device state is Microsoft Entra joined. Organizations with on-premises Active Directory can use Microsoft Entra hybrid joined devices if that model is selected during the review. The Conditional Access device filter is written against the join state, so a PC that is merely Entra registered does not pass.
Is Microsoft Entra registration enough to make a device trusted?
No. Registration creates a device identity, but it does not prove that the device is corporate-owned, approved, patched, encrypted, or free of malware. This service never describes a registered device as compliant — that distinction is written into the configuration summary you receive.
Do we need Microsoft Entra ID P1?
Yes, for every user the policies cover: Conditional Access, device filters, and authentication strengths are Entra ID P1 features. Microsoft 365 Business Premium and the Microsoft 365 E3/E5 suites include P1; Business Basic and Business Standard do not, and a P1 add-on for the covered users is the usual fix. Entra ID P2 risk-based policies are not required for this service.
What does it cost, and how long does it take?
The engagement runs two weeks. Week one is the access and licensing review, emergency-access validation, the device-onboarding procedure, and the trusted-device and authentication policies created in report-only mode; week two is registration follow-through, the mobile-access and email-protection configuration, test sign-ins, and enforcement of the policies you approve. It is scoped and quoted in writing after a short scoping call — device count, cloud-only versus hybrid join, the phishing-resistant method you choose, and the mobile-access mode all move the price — and the quote states the fixed price before any work begins; you pay after you approve delivery. The two-week window assumes the prerequisites are in place at kickoff — administrative access, the approved user and device lists, the mobile-access decision, and test devices; user registration of the phishing-resistant method is the step that can stretch it, which is why registration is guided before the authentication-strength policy is enforced.
Microsoft is retiring SMS and voice MFA — does this get us ahead of that?
Yes. Microsoft has announced that passkeys become the default registration experience in Microsoft Entra ID from September 2026 and that Microsoft-provided SMS and voice authentication is retired in February 2027; MFA is also already mandatory for Azure's administrative portals and command-line tools. Users who still rely on text-message codes will be pushed to change regardless. This service moves your selected users to a phishing-resistant method on a plan you control, with registration guided and tested before enforcement. Dates are Microsoft's and can shift; we confirm them at kickoff.
Does this include Conditional Access token protection?
Not in the base scope. Token protection is a session control that binds sign-in tokens to the Windows device so a stolen token cannot be replayed from another machine — a real answer to the token-theft risk this page is honest about. At the time of writing Microsoft supports it in general availability on Windows PCs for native Microsoft 365 apps against Exchange Online, SharePoint Online, and Teams; browser sessions are not covered and other platforms are in preview. Because the approved Windows PCs this service creates are exactly the devices it supports, it is a natural extension: we can run it in report-only mode during the pilot, tell you what it would break, and add it by written agreement.
What happens to users on iPhones and Android phones?
You choose one of two documented modes before implementation. Blocked Mobile Access prevents covered Microsoft 365 access from iOS and Android entirely — the clearest boundary without Intune. Restricted Mobile Access permits an agreed level of mobile access with the protections available, accepting in writing that an unmanaged phone cannot be treated as compliant.
Can mobile users keep email but be prevented from opening links?
No — and we would rather say so than sell it. Conditional Access governs access to applications and resources, not individual hyperlink actions inside Outlook mobile, and no supported tenant-level Outlook control disables every link. Rewriting mail flow does not solve it either: mobile apps recognize plain-text URLs and message rewriting damages legitimate business content. The honest choices are to block mobile access, or to keep it with Safe Links, anti-phishing protection, and phishing-resistant sign-in — and we will tell you which fits your risk tolerance rather than promise a control that does not exist.
Does the service include Microsoft Defender for Office 365?
It configures or reviews the email protection features already in your licenses; it does not supply licenses or features that are not in the tenant. If Defender for Office 365 would materially help — Safe Links and Safe Attachments are the usual reason — we say so and you decide, with our separate Defender for Office 365 implementation available when you want the full deployment.
Can Microsoft Defender for Endpoint device risk be used in Conditional Access without Intune?
Not through the standard enforcement model. Automated Conditional Access enforcement on Defender for Endpoint device-risk signals requires the compliance integration built on Microsoft Intune, which this Intune-free service deliberately excludes. Defender for Endpoint can still monitor and protect the devices independently.
What access does IT Partner need?
Time-bound, least-privilege access that you approve — granular delegated admin roles, never standing global administrator. For this scope that typically means the Conditional Access, authentication policy, cloud device, and Exchange or security administrator roles, documented before configuration begins and removed when the engagement closes. Emergency access accounts are validated before any policy is enforced.
What can cause users to be blocked unexpectedly?
Common causes: a device that is not correctly joined, an application or browser that does not present device identity, an unrecorded service account, an unsupported authentication path, a missing policy exclusion, a user who never finished passkey registration, or a dependency between Microsoft 365 services. That is exactly why every policy runs in report-only mode with test sign-ins before enforcement — the surprises surface in the pilot, not in production.
What happens after implementation?
You receive the configuration summary and take over approving new devices, reviewing exceptions, removing retired or lost devices, responding to security events, and maintaining the assigned licenses. If you want us to keep carrying it, managed Intune — once you adopt Intune — or our monitoring and administration services pick it up as separate engagements.