Microsoft Defender EASM - Simply Explained

What exactly can strangers see when they look at your company online? You might think of your company website, maybe your public LinkedIn page and your email address, but the public view is much bigger than that. There could be an old test website still online, a forgotten subdomain from a past project, a cloud service created by a team that has since moved on, or a public server, nobody has written down anywhere. These are digital doors and windows. They already face the internet, which means anyone can see them, not just your IT team. Most security tools start from inside your company and protect known devices, known users, and known files. An attacker starts outside, they don't need your company map or a login. They only need to look for what is visible. I'm Mirko Peters from M365FM, and in this knowledge nugget, we're going to look at Microsoft Defender, external attack service management, or EASM in plain English. You'll see how it finds public facing assets, why that list changes over time, and how a small clue you already know about can lead to something your team never knew existed. The problem, you can't lock what you can't see. Imagine your company as an office building. Inside you may have security at the front desk, staff use badges. Important rooms have locks. Cameras watch the main hallway, that's a good start. But someone walking around outside might find a side entrance that nobody checks anymore, maybe it belonged to an old team or contractor used it years ago. The sign has faded, but the door still opens. Online security has the same problem. Your IT team may keep a list of laptops, user accounts, approved applications, and company servers. The marketing team keeps a separate list of websites, a cloud team tracks its own services. A supplier runs another public site for a campaign, each list can be correct on its own. The trouble starts in the spaces between those lists. A project ends, but its test site stays online. Someone creates a subdomain for a short term event and forgets to remove it. A public IP address moves from one service to another, while the old records never change. A certificate reaches its expiry date and suddenly a website fails when customers try to use it. The internet doesn't care whether the service belongs to marketing, IT, a developer, or an outside supplier. If it responds to a request from the public internet, it can attract attention. An attacker's don't need to break into your office first to find it. They can search public records, look at domain names and website details, and inspect certificates, public IP addresses, and services that answer on the internet. They build a picture from clues that were already visible. You've probably seen a small version of this yourself. You search for your company name and find an old page still appearing in the results. Maybe it lists a phone number nobody uses anymore, or it refers to a product that no longer exists. For a security team, the same thing can happen with far more technical items. A domain can lead to a subdomain which can point to a host, which can reveal a public service. None of this means there is automatically a problem. Public websites need to be public, email systems need to accept messages, and remote access. Maybe there for a good reason. The issue is ownership and awareness. Can someone tell you who owns that asset? Do they know why it is public? Is it still needed? And if a weakness appears, does the right person know they need to fix it? This gets harder because a company's public footprint never stays still. People launch new websites, teams try cloud services, companies by other companies, vendors create portals, and developers build test systems. Then people change jobs, projects close, and the original reason for an asset disappears. That is often called shadow IT. Shadow IT means a tool, service, or system that operates outside the normal company list. It doesn't always come from bad choices. Often someone simply needed to get work done quickly. But if nobody knows it exists, nobody checks whether it is safe. So a yearly spreadsheet of public assets can become outdated very quickly. The old way it depends on asking every team, collecting their answers, and hoping nothing was missed. That gives you an inside view, but it doesn't prove what the internet can actually see. Microsoft Defender ESM starts from the other direction. It begins with a small clue about your company, then follows the public trail outward. What Microsoft Defender ESM actually is? Microsoft Defender external attack service management is Microsoft service for finding, slapping, and monitoring the parts of your company that face the public internet. That's a mouthful, so let's break it down in plain English. External means outside your company network. On the public internet where anyone can see. A attack service refers to every public spot that someone or something could reach, inspect, or try to misuse, and management means keeping that picture up to date so your team can review it and take action when something needs attention. Put those three words together, and ESM gives you an outside view of your company's public footprint. Think of a property inspector walking along a row of business units. They don't enter every room or read every file inside. Instead, they check only the parts visible from the street, which entrances exist, which signs point to the business, which windows are broken, and which old storage door still has a lock, but no one seems responsible for it. Defender ESM works the same way online. It can find domains and subdomains like Contoso, Com and Events, dot Contoso.com, identify hosts that are named systems connected to those addresses, and map public IP addresses, web pages, certificates, and internet services linked to your company. Make certificates as an example. When you visit a secure website, your browser checks a digital certificate to prove which site you reached and protect the connection. But certificates also leave public clues about names connected to a company, and ESM uses those clues as part of its view. It can also show connections that matter. A company domain may point to a website, which connects to a host, which uses a public IP address where a service might be answering. Looking at each item alone gives you a list, but seeing how they connect gives you context. Many people hear the word Defender, and assume ESM protects every device or blocks every attack, but it doesn't work that way. ESM doesn't replace a firewall, patch old software, or take the place of antivirus on laptops, email protection, or cloud security settings. Those tools handle different jobs, a firewall controls traffic, patching fixes software problems, and Microsoft Defender for Endpoint Protects devices. ESM helps you see what the public internet can find before you decide what needs fixing, removing or watching. You need both views. The tools inside your company can tell you about devices and services you already manage, but ESM starts from the outside and asks a different question. If someone knew nothing about your company except its public name, what could they discover? That outside view can uncover a service your internal inventory missed, and it can also confirm that an internet-facing application you already know about still looks the way you expect from the public side. And that difference matters. A long-asset list by itself can feel like more work, not more security. A useful part comes from how Defender ESM turns public clues into a connected picture that helps you separate the assets that belong to you from the ones that don't. How Discovery works? From one known clue to a map. So how does Defender ESM find things your company never put on a list? It starts with a seed. A seed is a known piece of public information that points ESM toward your company. It could be a domain like Contoso. Com, a public IP address, or range, a host name, an email contact, an autonomous system number, ASN for short, or a company name found in public domain registration details, an ASN sounds technical, but the idea is simple. Internet providers and large organizations use ASNs to identify the networks they run. So if your company owns part of a public network, that number can help point Discovery toward the right place. You don't need every seed before you begin. In fact, that would miss the point. You give Defender ESM the clues you already trust, and it uses public connections around those clues to build a wider picture. Imagine you know one public website address. Internet address might reveal a subdomain like portal, Contoso.com, and a public certificate connected to that subdomain may contain other names. One of those names can point to a host, which may connect to a public IP address where a web service or another internet facing service responds. Each clue leads to another clue. Microsoft calls this recursive discovery. In plain English, ESM finds a public relationship, checks where it leads, then keeps following connected information to figure out what likely belongs to your company. It doesn't need a company user account. It uses information that already appears on the public internet like domain records, certificates, host names, web content, and the public behavior of services. These are the same kinds of clues and outside researcher or an attacker can use to build a map. But finding a connection doesn't automatically prove ownership, and that part matters a lot. A public IP address might belong to a shared cloud provider, a certificate could include names for several customers, and a website may use a service run by a supplier. And a ESM helps you investigate those relationships, but your team still needs to decide what actually belongs to your company. Think about a business that uses a web agency for a short campaign. The campaign domain might point to systems owned by the agency, so some parts are yours, some belong to the agency, and some are shared services used by many customers. Treating every related item as your asset would create noise and confusion, so ESM gives you a starting point for that ownership conversation. You can create discovery groups to keep the search focused. A discovery group might cover your main company name, another could focus on a new brand or business unit, and you can also build a group around known domains and public IP ranges. That approach helps when a large company has separate teams and separate public services. Instead of one huge pile of results, you can ask more focused questions. What does the public internet show for this brand? What changed around this business unit? And which assets connect to the domains used by this product team? You can also exclude items that you already know don't belong in the inventory that doesn't erase the public record. It simply keeps your working view cleaner so your team can spend time on the assets they can actually manage. Discovery also isn't a one-time job. A company can launch a new public service on Monday, change a cloud setting on Wednesday, and retire a site on Friday without removing every public reference. The public footprint changes because the business changes, so a weekly recurring discovery schedule is a sensible starting point for many organizations. You can also run discovery once for a snapshot, but regular discovery keeps the inventory connected to real life. A new seed can lead to a new branch of public information, and boom, that's often where teams find something they didn't expect. Not because Defender EASM creates the asset, but because it connects clues that existed separately until someone looked at them together. Still, discovery only gives you the map. A map can show hundreds of domains, IP addresses, certificates, and services. The next question is harder. Which of those findings need attention first? What should your team actually do about them? From inventory to action? What EASM helps you spot? So once Defender EASM builds an inventory, you need to treat it as a living record, is not the final answer. Some items are recent, showing what EASM has seen as part of your current public footprint. Others are historic. They were visible at some point, but may no longer respond or connect the same way, even so that older records still has a purpose. Imagine an incident starts with a suspicious domain name or an IP address found in a log. A historic record can tell you that this address once connected to an old business service, even if that service disappeared months ago, that helps your team figure out who used it, what it did, and whether a related system might still exist. The inventory also keeps the links between items visible. A domain name may connect to a certificate. That certificate may connect to several host names. Those hosts can lead to public IP addresses and services. When you see that chain, you stop treating each result as a random technical detail. You can ask better questions. Does this public login page belong to the same team as the main website? Does this certificate point to an old product name? Is this exposed service part of an approved cloud setup or did someone leave it behind after a test? That's where observations come in. An observation is something defender EASM has noticed that may need review. It could be a forgotten subdomain in old web page still appearing online, a remote access service exposed to the public internet, or a setup choice that doesn't match your company rules. Certificates also need attention. An expired certificate can stop a website from loading properly and create warnings for users. A certificate that will expire soon gives the owner time to renew it before customers or staff run into a broken service. But EASM doesn't only collect technical names and dates. Microsoft uses virtual user technology to revisit public web content and check how a page behaves from the outside. Think of it as a fresh visitor arriving at the site, rather than relying only on an old record from months ago. That can show whether a page changed, whether it still loads and what public content or behavior it exposes. This gives security teams current evidence when they investigate a web facing asset. But here's the thing. Most people mess up at this point. This year long list of findings and treat every item as equally urgent. That creates a queue nobody can realistically work through. A public asset needs context before it becomes a priority. First, ask how exposed it is. A public administration page needs more care than a simple information page. Then ask whether there is a known weakness or unsafe setup. After that, look at business importance. A public customer portal and a forgotten event page don't carry the same risk even if both sit on the internet. Finally, find an owner. Without a named owner, a finding often moves from one team to another until nobody fixes it. Ownership turns a technical observation into a piece of work that someone can accept, change, remove or explain. Take a common example. The marketing team launches a campaign site for a new product. The campaign ends six months later. But the site remains online. The agency that built it has moved on. The internal project lead changed roles. The site runs an older version of its web software and it still shows a public login page. Nothing may have gone wrong yet. Still, this is the kind of asset that deserves a decision. Is it still needed? Who owns it? Can the software be updated? Should the login page stay public? Or should the site come down entirely? The action path can stay simple. Confirm who owns the asset. Decide whether it belongs to your company and whether it still has a business purpose. Then fix the problem, remove the asset, or keep watching it if it must stay public. Record that decision so the next person doesn't need to start the same investigation again. Not every discovery is an emergency. And not every public service should disappear. Your website, customer portal and public email service exist because people need to reach them. The goal is control. You want every visible asset to have a reason for being there, a person or team responsible for it and the right level of protection. Once that outside record exists, it can do more than support one security review. It can feed the teams already responding to alerts and managing risk across Microsoft security tools. How EASM fits into Microsoft security. Defender EASM becomes more useful when it connects with the security work your teams already do. Think of it as the outside patrol around your company. It watches what the public internet can reach while other Microsoft security tools help protect the people, devices, email and cloud services behind those public facing services. Microsoft Defender for endpoint focuses on devices such as laptops and servers. Microsoft Defender for Office 365 helps protect email and collaboration. Microsoft Defender for Cloud helps teams find and manage security issues in cloud workloads. Defender EASM adds a different view. It asks what is visible before an attacker reaches any of those systems. Security also belongs in this picture. Entra ID is the reception desk for your digital identity. It manages who signs in what they can access and how their account proves who they are. If an exposed application uses company sign-in, security teams may need to understand both sides. The public application that someone can reach and the identity controls protecting access after they arrive. These tools don't compete with each other. They cover different parts of the same company. Microsoft Security Exposure Management brings these views closer together. It gives security teams a broader picture of exposure across Microsoft security products so they can look beyond one alert or one device and see where risks connect. For example, a public facing server might appear in Defender EASM while cloud security data shows how that server is set up. A security team can use both pieces of information when deciding what to fix first. EASM can also send its findings to places where teams search and investigate security data. Through data connections, you can export asset data, attack surface insights, or both. Acid data means the discovered items such as domains, hosts, IP addresses and services. Attack surface insights mean the observations and risks connected to those items. One destination is log analytics. Log analytics is a place where you store and search data from Microsoft services. Security teams can use it to ask questions across many sources rather than opening a separate tool for every answer. Another destination is Azure Data Explorer. That is built for teams that need to store and query large amounts of data quickly, especially when they want to build their own reports or combine EASM data with other records. Microsoft Sentinel can use that exported data too. Sentinel is Microsoft's Security Operations Platform. It collects security signals, helps analysts investigate incidents, and can trigger follow-up actions through playbooks. When EASM findings appear alongside alerts and logs, an analyst can quickly check whether an incident involves a public facing asset, what else connects to it, and whether the asset already carried a known concern. That can reduce guesswork during an investigation. Security co-pilot adds another way to work with the data. Instead of searching through lists manually, you can ask questions in plain English. You might ask which internet facing assets connect to a certain domain, what observations exist for a public service, or where a newly found host fits in the company's public footprint. Co-pilot doesn't replace the need for human review. It helps teams get to the right questions faster, while the people responsible for security still decide what the findings mean and what action makes sense. You don't need every connection on day one. Start by making the outside view part of your regular security routine. Then let the process become more useful as your inventory, ownership records, and incident workflows improve. A simple starting plan. Start with what you already know. Your main company domains and approved public IP ranges. If you know the public names used by a brand, product, or business unit, add those two. Create a discovery group and let the inventory build over time. The first results will include items your team recognizes right away. Plus some assets that need a closer look. Now bring the right people into that review. Your website team knows the public pages. Your cloud team recognizes the hosts. Network staff can identify IP addresses. Security helps judge the exposure. A supplier may need to confirm if they run part of the service. Label the result clearly. Market as owned, shared, no longer needed, or outside company control. That simple decision stops the same unknown asset from coming back as a mystery every few months. Set a regular discovery schedule and a regular review meeting. Then turn findings into small actions. Close and expose service that shouldn't be public, renew a certificate before it expires, or remove a site that no longer needs to be online. Over time, your team gets fewer surprises when a new public service appears or an incident begins. Microsoft Defender ESM helps you see the public facing parts of your company before an attacker turns an overlooked asset into a target. Think of it as watching the outside of your building. You want to know what's exposed before someone else does. Here's a simple challenge. Write down three public domains your company uses. For each one, ask who owns it, why it needs to stay online, and who would fix it if something changed tomorrow. That exercise reveals where the gaps are. For the next knowledge nugget, keep building the full Microsoft Security picture with Defender and Microsoft Security Exposure Management. The public view tells you what strangers can find. The inside tools help you understand what those public services can reach.