Setting up MFA or user permissions? Separate identity, policy and access.

Ask the responsible administrator to inspect the actual tenant configuration: Security defaults, Conditional Access where licensed and configured, and any existing policy or migration dependencies. Registering a phone or installing an app does not itself require MFA for every application and session. A quiet sign-in also does not by itself show MFA is off; an existing session or supported authentication method may already satisfy the requirement.

Security defaults provides preconfigured protections; Conditional Access allows more specific conditions when the required licensing and configuration are in place. Do not toggle either control or create exclusions from a generic guide. The administrator should assess existing protection, legacy clients, affected users and continuity, then use a controlled rollout and review the resulting sign-in evidence.

Authentication method strength matters too. A push approval or code is not automatically phishing-resistant. Microsoft supports phishing-resistant options such as permitted FIDO2/passkey methods, subject to the actual device and policy. Passkeys in Authenticator are different from ordinary Authenticator push approvals. Do not promise that any MFA prevents every compromise or that every sign-in must show a fresh prompt.

Write down the actual task and resource: viewing a particular document, editing a team library, accessing a mailbox or administering a service. Confirm the intended person’s exact work or guest identity, required view/edit/administration level, business owner and duration. Being able to sign in does not entitle someone to every resource.

Distinguish a Microsoft 365 licence, group membership, resource permission, Entra/service administrative role and an application’s consent. Each affects different things. Do not assign Global Administrator, approve organisation-wide app access or add someone to a broad group just to open one file. Use least privilege: the permissions needed over the appropriate scope and time.

For a sharing problem, review the actual source and intended audience using the file sync and sharing guide. For a licensed feature, check the licence guide. Neither adding a licence nor registering MFA substitutes for the resource owner’s permission decision.

Have the authorised owner review current direct permissions, relevant group membership, inherited access and sharing links for the actual resource. A restricted new link does not remove access already granted another way. Removing a direct permission may also leave access through a group. Record the actual effective access rather than judging by one invitation.

For administrative work, the role owner should choose an appropriate documented role and scope, with time-limited privileged access where the organisation supports it. Protect administrative identities and retain the organisation’s established recovery and emergency-access arrangements. Do not create a new shared admin account, assign a broad role or change emergency-access policy as a shortcut.

For an approved access change, agree the precise effect, affected people, duration, rollback/recovery and verification with the owner before implementation. If current access is already correct, proceed to verification without an unnecessary grant. If the correct owner or business authority is uncertain, stop and resolve that first.

The authorised resource or role owner should use the supported administration or sharing control for that exact task. Confirm the recipient, resource and view/edit or role level before applying the agreed change. Follow the organisation’s approval process and record the owner, reason, scope, date and review or expiry requirement.

Do not broaden an entire site, expose an Anyone link, grant application consent or turn off a security requirement to fix one access denial. An app’s request to read data is a separate assessment of the app, publisher, permissions and organisation policy. It is not an ordinary user permission implied by installing the app.

When somebody changes role or leaves, arrange the organisation’s full access and data-continuity process. Removing one group or link does not establish that all access or active sessions have ended, and deleting an account can affect business data. Keep offboarding, record retention and ownership transfer within an authorised plan rather than treating this guide as a complete offboarding checklist.

Privately record the exact error, time, account/organisation, intended resource and whether the failure is registration, authentication or resource access. Avoid screenshots containing setup codes, access tokens or private document content. Ask the responsible administrator to assess relevant registration, sign-in and policy evidence; ask the resource owner to check effective permissions.

If the only method is lost or unavailable, use the organisation’s established identity-verification and recovery process. Do not approve random prompts, borrow another identity, remove all methods, reset every device or disable MFA to continue. A report-only policy result or permitted method setting is not proof the intended enforced access works.

Unexpected approvals, changed methods or suspicious access need the organisation’s incident process promptly. A successful password reset or newly working app is not proof that an account compromise is resolved. For ordinary unresolved access, keep existing permitted work and recovery intact while the owner investigates.

Use the organisation’s known IT, identity or resource owner for uncertain MFA enforcement, lost-method recovery, privileged roles, unfamiliar app consent or a wider access review. Privately provide the intended account/organisation, task, affected resource and relevant error/time. Never send passwords, enrolment QR codes, one-time codes or the full private data set.

Our Microsoft 365 support can discuss a scoped assessment and appropriate owner involvement. Agree authority, continuity, approved changes and verification before work. A working login alone does not prove every permission or policy is right, and this guide does not certify compliance or guarantee an account cannot be compromised.