Losing Access to Exchange Online

Akins IT • March 26, 2020

At Akins IT, we pride ourselves in ensuring that our clients are made aware of technological updates that have a high likelihood of impacting their environments. Today’s update is in regards to Microsoft’s discontinuation of support for Basic Authentication for Exchange Online. This change will make Exchange Online more secure by preventing bad actors from bypassing Microsoft security features that are incompatible with Basic Authentication, such as MFA and Conditional Access.

At this time, Microsoft has indicated that this change will now go into effect during the second half of 2021- as opposed to the previous date of October 13, 2020. Microsoft will release a more precise date once they have a better understanding of the impact of COVID-19. Basic authentication will be disabled for newly created tenants by default and starting October 2020, disabled for tenants that have no recorded usage.

Once in effect, this change will result in the retirement of Basic Authentication for EWS, EAS, IMAP, POP and RPS to access Exchange Online. Any application using OAuth 2.0 and connecting with the aforementioned protocols will continue to work without change or interruption. This change does not impact SMTP AUTH.

What do I need to do to prepare for this change?

Start by updating the client applications your users are using to versions that support OAuth 2.0
Mobile devices should use the Outlook app for the best support, or other email apps that support Modern Authentication
Desktop/laptops should use Outlook 2013 or newer
Developers should ensure that any code they have written is updated to support OAuth 2.0
Confirm that any 3rd-party applications which access Exchange Online support OAuth 2.0 or switch to comparable applications that do support OAuth 2.0

You may refer to the following Microsoft blog from the Exchange Team to learn more about this retirement:

https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-auth-and-exchange-online-february-2020-update/ba-p/1191282L

Please reach out to us at Akins IT, if you would like to discuss this change in more depth and discover how your organization could benefit from implementing MFA and Conditional Access today!

< Older Post

Newer Post >

AWS stumbled this morning. Here’s why multi‑cloud keeps you moving.

By Shawn Akins • October 20, 2025

October 20, 2025 — Early today, Amazon Web Services experienced a major incident centered in its US‑EAST‑1 (N. Virginia) region. AWS reports the event began around 12:11 a.m. PT and tied back to DNS resolution affecting DynamoDB , with mitigation within a couple of hours and recovery continuing thereafter. As the outage rippled, popular services like Snapchat, Venmo, Ring, Roblox, Fortnite , and even some Amazon properties saw disruptions before recovering. If your apps or data are anchored to a single cloud, a morning like this can turn into a help‑desk fire drill. A multi‑cloud or cloud‑smart approach helps you ride through these moments with minimal end‑user impact. What happened (and why it matters) Single‑region fragility: US‑EAST‑1 is massive—and when it sneezes, the internet catches a cold. Incidents here have a history of wide blast radius. Shared dependencies: DNS issues to core services (like DynamoDB endpoints) can cascade across workloads that never directly “touch” that service. Multi‑cloud: practical resilience, not buzzwords For mid‑sized orgs, schools, and local government, multi‑cloud doesn’t have to mean “every app in every cloud.” It means thoughtful redundancy where it counts : Multi‑region or multi‑provider failover for critical apps Run active/standby across AWS and Azure (or another provider), or at least across two AWS regions with automated failover. Start with citizen‑facing portals, SIS/LMS access, emergency comms, and payment gateways. Portable platforms Use Kubernetes and containers, keep state externalized, and standardize infra with Terraform/Ansible so you can redeploy fast when a region (or a provider) wobbles. (Today’s DNS hiccup is exactly the kind of scenario this protects against.) Resilient data layers Replicate data asynchronously across clouds/regions; choose databases with cross‑region failover and test RPO/RTO quarterly. If you rely on a managed database tied to one region, design an escape hatch. Traffic and identity that float Use global traffic managers/DNS to shift users automatically; keep identity (MFA/SSO) highly available and not hard‑wired to a single provider’s control plane. Run the playbook Document health checks, automated cutover, and comms templates. Then practice —tabletops and live failovers. Many services today recovered within hours, but only teams with rehearsed playbooks avoided user‑visible downtime. The bottom line Cloud concentration risk is real. Outages will happen—what matters is whether your constituents, students, and staff feel it. A pragmatic multi‑cloud stance limits the blast radius and keeps your mission‑critical services online when one provider has a bad day. Need a resilience check? Akins IT can help you prioritize which systems should be multi‑cloud, design the right level of redundancy, and validate your failover plan—without overspending. Let’s start with a quick, 30‑minute review of your most critical services and RPO/RTO targets. (No slideware, just actionable next steps.)