How to lock down your Microsoft account and keep it safe from outside attackers

You can get a Microsoft account for free, but that doesn't begin to describe its value, especially if you use that account for crucial email and cloud storage. Follow these seven steps to establish a solid baseline of security and protect that account from intruders.

04 January 2021

What's your most valuable online account, the one most deserving of protection? If you use a Microsoft account to sign in to a Windows PC, that account and its associated email address should be the one you guard most jealously. That's especially true if you use that Microsoft account for OneDrive storage and Office 365 documents.

In this post, I list seven steps you can take to help you lock that account down so it's safe from online attacks. As always, there's a balancing act between convenience and security, so I've divided the steps into three groups, based on how tightly you want to lock down your Microsoft account. (It's worth noting that this article is about consumer Microsoft accounts used with Home and Personal editions of Office 365, Microsoft 365, and OneDrive. Security settings for business and enterprise Microsoft 365 accounts are managed by domain administrators through Azure Active Directory, using a completely different set of tools.) 


This level is sufficient for most ordinary PC users, especially those who don't use their Microsoft email address as a primary factor for signing in to other sites. If you're helping a friend or relative who's technically unsophisticated and intimidated by passwords, this is a good option.

At a minimum, you should create a strong password for your Microsoft account, one that's not used by any other account.

In addition, you should turn on two-step verification (Microsoft's term for multi-factor authentication) to protect yourself from phishing and other forms of password theft. When that feature is enabled, you have to supply an additional proof of your identity when you sign in for the first time on a new device or when you perform a high-risk activity, such as paying for an online purchase. The additional verification typically consists of a code sent as an SMS text message to a trusted device or in an email message to a registered alternate account.


Those baseline precautions are adequate, but you can tighten security significantly with a couple extra steps.

First, install the Microsoft Authenticator app on your iPhone or Android device and set it up for use as a sign-in and verification option. Then remove the option for using SMS text messages to verify your identity.

With that configuration, you can still use your mobile phone as an authentication factor, but a would-be attacker won't be able to intercept text messages or spoof your phone number.


For the most extreme security, add at least one physical hardware key along with the Microsoft Authenticator app and, optionally, remove email addresses as a backup verification factor. That configuration places significant roadblocks in the way of even the most determined attacker.

It requires an extra investment in hardware and it definitely adds some friction to the sign-in process, but it's by far the most effective way to secure your Microsoft account.


First things first: You need a strong, unique password for your Microsoft account. The best way to ensure that you've nailed this requirement is to use your password manager's tools to generate a brand-new password.

(No password manager? Try an online option like the 1Password Strong Password Generator or the LastPass Password Generator Tool.)

Generating a new password ensures that your account credentials are not shared with any other account; it also guarantees that an older password that you might have inadvertently reused isn't part of a password breach.

To change your password, go to the Microsoft Account Security Basics page at Sign in, if necessary, then click Change Password.















Generate a brand-new password to ensure that you aren't accidentally reusing an old one.

Follow the instructions to save the new password using your password manager. Feel free to write it down, if you prefer a physical backup. Just make sure to store the paper in a secure location, such as a locked file drawer or a safe.


Print out a recovery code and store it in a safe place; you'll need it if you lose access to your account.

Next step is to save a recovery code. If you're ever unable to sign in to your account because you've forgotten the password, having access to this code will save you from being permanently locked out.

On the Microsoft Account Security Basics page, find the Advanced Security Options section and click Get Started. That takes you to the not-so-basic Microsoft Account Security page. (To go there directly, bookmark this address:

Scroll to the bottom of the page and look for the Recovery Code section. Click Generate A New Code to display a dialog box like the one shown here.

Print out that recovery code and file it away in the same locked file cabinet or safe where you put your password.

(Microsoft allows you to generate only one code at a time for a Microsoft account. Generating a new code renders the old code invalid.)


Don't leave the Microsoft Account Security page just yet. Instead, scroll up to the Two-Step Verification section and make sure this option is turned on.

The setup process is a fairly straightforward wizard that confirms you are able to receive verification messages. If you're using a modern smartphone with an up-to-date version of iOS or Android, you can safely ignore the prompts to create an app password for the mail client on those phones.

And now for some more advanced security options.


Use this dialog box to add secure verification options to your account.

Microsoft recommends that you have at least two forms of verification available in addition to your password. If you need to reset your password, when two-step verification is enabled, you'll need to supply both of those forms of identification or you risk being permanently locked out.

A free email address, such as a Gmail account, is acceptable if your security needs are minimal, but a business email address is a much better choice. If necessary, you can have a verification code sent to that address.

Go to the advanced Microsoft Account Security page and click Add A New Way To Sign In Or Verify.

Choose the Email A Code option, enter your email address, and then enter the code you receive to confirm that verification option.


Smartphone apps that generate Time-based One-time Password Algorithm (TOTP) codes are an increasingly popular form of multi-factor authentication, and I highly recommend their use for any service that supports them. (For more on these options, see "Protect yourself: How to choose the right two-factor authenticator app.")

Even if you use another authenticator app for most services, I recommend using Microsoft Authenticator for use with your Microsoft account. In this configuration, any sign-in attempt that requires verification sends a push notification to your smartphone. Approve the request, and you're done.

An added bonus is that the Microsoft Authenticator app can be used for passwordless sign-in as well as verification.

To set up Microsoft Authenticator with a Microsoft account, go to the advanced Microsoft Account Security page and click Add A New Way To Sign In Or Verify. Choose the Use An App option and then, after installing the Microsoft Authenticator app, sign in using your account credentials.


By this point, you should have more than enough secure ways to authenticate yourself and verify your identity. That means it's time to remove the weakest link in the chain: SMS text messages.

What makes SMS text messages so problematic from a security point of view is the reality that an attacker can hijack your mobile account. It happened to my ZDNet colleague Matthew Miller a few years ago, and I wouldn't wish that nightmare on anyone. (For details and some additional security advice, see "Protect your online identity now: Fight hackers with these 5 security safeguards.")

Before you change this setting, confirm that you have at least two alternative forms of verification (a secure email address and the Microsoft Authenticator app, ideally) and that you've saved a recovery code for the account. Then, from the advanced Microsoft Account Security page, expand the Text A Code section.

After you've added more secure verifications options, remove the weak link of SMS text messages.

Click Remove to eliminate this option.


Using a hardware key, you can sign in to your Microsoft account with just a PIN. 

This step is the most advanced of all. It requires an investment in extra hardware, but the requirement to insert a device into a USB port or make a connection via Bluetooth or NFC adds the highest level of security.

For an overview of how this type of hardware works, see "YubiKey hands-on: Hardware-based 2FA is more secure, but watch out for these gotchas."

To configure a hardware key, go to the advanced Microsoft Account Security page and click Add A New Way To Sign In Or Verify. Choose the Use A Security Key option and then follow the prompts.

You'll need to enter the PIN for your hardware key, then touch to activate it. When that setup is complete, you've got a powerful way to sign in to any service powered by your Microsoft account without having to fuss with passwords.

As I mentioned at the start of this article, most people don't need this level of advanced protection. But if your OneDrive account includes valuable documents like tax returns and bank statements, you'll want to lock it down as tightly as possible.

Data 2021 Outlook Part II: Hedging the cloud

Over the next year, the issue of cloud vendor lock-in won't be quite so cut and dry.

07 January 2021

On Twitter, one of our most commented-on posts last year was when we when we reviewed the hype around multi-cloud. With a few exceptions (e.g., disaster recovery, public regulation), we remain cynical about the viability of running a single database logical instance across multiple clouds; we believe that for most organizations, a "multi-cloud" platform will in essence mean "freedom of cloud." Run the database or cloud control plane of choice in the public or private cloud of choice. We haven't exactly been a lone voice in the wilderness about the operational complexity of running a single instance of a database or application across multiple clouds; Matt Asay, Corey Quinn, and Gartner have shared similar concerns.

But we expect that freedom of cloud will have a louder ring in the coming year. It's not exactly like organizations will take their first halting steps into some alien cloud. We've noted that variety – intentional or otherwise – has long been the spice of life (and often, administrative headache) for most organizations. Chances are, the larger and more diverse the enterprise, the more likely they are to have one of everything, and why should that be any different with cloud? But as we note below, the choices over freedom of cloud won't necessarily be completely clear-cut.


Managed services are pushing this dialog to the forefront, and it's why we think it will start proving an evergreen issue in the coming year. It's a tactical decision to put your DevTest or database on EC2 at AWS, whereas it's a strategic decision should your organization choose to run managed services such as Amazon Aurora PostgreSQL database or SageMaker, because at that point, you are not choosing a cloud to run some random compute cycles on, but a platform. You're making the Microsoft vs. Oracle decision all over again, but with a new and wider cast of the usual suspects and emerging players (Snowflake, Confluent, Databricks, anyone?).

In the 2020s, your choice of cloud platforms will drive your systems, tools, databases, and application choices. But just as it looked like the battle lines are hardening – e.g., choose Google Cloud SQL or AI Platform, and you can only run them on GCP – hybrid is changing all that. Hold that thought.

Conventional wisdom is that any form of lock-in is bad, but for most organizations, at some layer of the stack, it is inevitable. It's hardly a new issue, and, unless your organization homebrews all of its applications and databases and relies on itself for support, it will have to make some strategic technology choice somewhere. Your organization is choosing a platform that will drive its decisions around tools, databases, and applications. The technology provider for that strategic layer becomes, in effect, first-among-equals and a form of gateway: all other software choices must come either through the partner ecosystem or from suppliers who support and/or integrate to that platform.

During the mainframe era, that decision was driven by the system, but the emergence of distributed systems shifted that choice, first to the OS, and then to applications and/or databases. In the run-up to Y2K when modern enterprise applications and databases were implemented, that set the stage for the rivalry of Oracle and SAP: Which provider drove your choice of third party solutions?


As enterprises are accelerating their embrace of the cloud, the choice becomes, appropriately enough, clouded. As we noted above, choosing from the cloud provider's portfolio of managed services likely ties you to that platform, because they are only run on that provider's cloud. Yes, we've italicized that term for a reason, and we'll get back to that in a moment.

Azure and Oracle Cloud excepted, most of the cloud providers have focused their managed services at the Platform-as-a-Service (PaaS) level, for databases, application development environments, integration, internet of things, analytics, and so on; they have not pursued enterprise SaaS applications. So, with PaaS, or in this case, Database-as-a-Service (DBaaS), enterprises have the choice: select a MongoDB-compatible database from AWS or Azure, or go to MongoDB Atlas for a MongoDB database that should promise an identical experience regardless of cloud. Until now that choice has been pretty black and white: stick with the cloud provider's service, which sticks you to that cloud, or go third party and feel free to choose the cloud.

That's where we rewind the tape and bring you back to that term "likely," regarding cloud vendor lock-in. In the coming year, we expect the lines to blur a bit as cloud providers raise the volume on their multi-cloud messages, while some third parties designate specific cloud providers as preferred partners that may involve joint go-to-market, support, and in some cases, joint product development.

And we could imagine a scenario where, for specific services they want to promote, some cloud providers may lower hurdles, such as selectively doing away with egress charges. For instance, we could well imagine Google Cloud getting creative here in promoting its AI services to customers running applications on AWS or Azure.


For starters, let's look at hybrid cloud platforms, an area where we surveyed the market landscape last year. Google Cloud and Microsoft Azure have made noises about their software-defined hybrid platforms being able to run in alien territory, with Google Cloud Anthos now formally supported for running in AWS. Kubernetes (K8s) is supposed to be the great leveler that allows all this to happen. Keep in mind that each cloud provider's managed K8s service will be implemented slightly differently; for instance, GCP Anthos and IBM Red Hat OpenShift implement administrative functions for the Istio service mesh in their K8s offerings a bit differently. Nonetheless, with some tweaks, all those microservices should be portable.

But comparing K8s platforms is simply about the cloud control plane. What about the portfolios of higher-value managed PaaS services? At this point, the pickings are pretty slim. On Azure Arc, Microsoft currently only offers a couple of Azure data services (Azure SQL Managed Instance and PostgreSQL Hyperscale), while Google has just introduced BigQuery Omni (the extension of BigQuery that runs in Anthos on foreign soil).

The story is similar for AWS Outposts, although it is a bit of a different case. No, it's not a K8s platform, but instead is a turnkey system running in the customer's data center, not a foreign cloud environment. For now, Outposts runs a curated selection of AWS services including containers (Amazon ECS or EKS); RDS for MySQL or PostgreSQL database; and EMR for analytics.

It's going to be a long while, if ever, when a critical mass of all those analytics, AI, database, integration tools, IoT, and other services any of the cloud providers makes it onto hybrid cloud systems, and potentially, cross-cloud software-defined offerings. But in the long run, we expect the 80/20 rule to apply with the most popular data, analytics, and machine learning services likely to make it to software-based hybrid clouds that venture into rival territory.


At the other end of the spectrum, will you necessarily get the same third party experience across every cloud? What's emerging in open source databases, and we expect, AI and analytics tools, is that a growing array of third parties will anoint specific cloud providers as first among equals. Here are a few examples:

  • Microsoft Azure has been especially proactive with its Embrace partnership with SAP for its S/4HANA NextGen ERP cloud service; SAS with its NextGen Viya cloud service; Redis, as a full stack alternative to Azure's cache-only offering; and Azure Databricks, a third-party service with native integration to Azure Machine Learning and other services.

  • Google Cloud has also been prominent with its extensive roster of open source database partnerships that, for now, involve joint sales and support, but in the future could also involve some tighter integrations with other GCP services.

  • AWS has cracked open the door with its new Managed Grafana service based on a joint go to market and product development partnership that we covered a couple weeks back.

In each of these cases, the third party services in question are, or will be offered in other clouds. But for these partnerships, some cloud providers will jump to the head of the line. In the coming year, we expect that the dividing line for cloud vendor lock-in will start to blur. Yes, for 95% of all managed services in the cloud provider's portfolio, your choice will continue to shape which public cloud (and in some cases where availability is limited, which cloud region) you run in. And for most third-party tools, applications, and databases, those with plans to support all major cloud providers will commit to delivering common experiences.

But in limited cases, cloud providers will penetrate enemy territory and third parties will feature preferred relationships with specific cloud providers, and this is what we expect to see more of this year. The issue of cloud lock-in will gradually take on shades of gray.