> ## Content Index
> Fetch the complete content index at: https://guardians-of-kings-landing.ghost.io/llms.txt
> Use this file to discover other available public pages before exploring further.

# The Raven's Seal: Additional Context in Authenticator Notifications
- URL: https://guardians-of-kings-landing.ghost.io/the-ravens-seal-additional-context-in-authenticator-notifications/
- Published: 2026-11-10T13:30:00.000Z
- Updated: 2026-11-10T13:29:59.000Z
- Author: Kevin Villarreal

Alright, Guardians. In Westeros, no lord opens a letter without checking the seal first. A direwolf means Winterfell. A lion means trouble from King's Landing. A raven with no seal at all? Could be from anyone and anyone is exactly who you should worry about.

Now picture your phone buzzing. "Approve this sign-in?" Enter the number shown. That's it. No app, no place, no clue who's knocking at the gate.

Number matching stopped the blind "tap Approve to make it go away" problem. But it doesn't answer the two questions a user should be asking before they type that number: **what am I signing in to, and where am I signing in from?**

That's what additional context does. It adds the application name and the sign-in location to Microsoft Authenticator push and passwordless notifications. It's the seal on the raven's letter. Or, if you're a Destiny player, it's your Ghost scanning the door before you walk through it: "Guardian, this signal is coming from somewhere you've never been."

Here's the catch that inspired this post: if your tenant shows it as **Microsoft managed**, you might assume the seals are already being checked. They aren't.

## Reading the seal: what the user actually sees

With additional context on, an Authenticator push or passwordless notification shows two extra details:

- **Application name:** the app requesting the sign-in, such as Office 365 Exchange Online or Azure Portal.
- **Geographic location:** where the sign-in came from, based on the IP address of the device signing in.

Combined with number matching, a user now has three things to check before approving: the number, the app, and the place. If they're sitting in Austin and the prompt says a sign-in to the Azure Portal from somewhere they've never been, they don't need security training to know what to do. That raven didn't come from Winterfell.

### The old raven vs. the new raven

If you've been around Authenticator for a while, this is the version you probably remember:

![location-with-number-match.png](https://storage.ghost.io/c/bf/77/bf77821b-a321-4933-a591-722e54071e18/content/images/2026/11/location-with-number-match.png)

The old prompt was a small pop-up over the app: "Are you trying to sign in?", the tenant and account, the app and location stacked as plain text, a map, a single text field for the number, and two buttons, "No, it's not me" and "Yes." It worked, but it was easy to tap through on autopilot, like a Guardian skipping every cutscene to get back to the loot.

Here's the redesigned prompt on iOS today, with number matching and both settings enabled:

![IMG_0667.PNG](https://storage.ghost.io/c/bf/77/bf77821b-a321-4933-a591-722e54071e18/content/images/2026/11/IMG_0667-1.PNG)

The prompt reads "Approve this sign-in?" with the tenant name and the account signing in right under it, then the boxes for the number. Below that sits a new card: **Location: TX, United States**, **App: Azure Portal**, and an Apple Maps snippet centered on where the sign-in came from (Austin, in this case). Deny and Approve sit under the card, with Approve greyed out until the number is entered.

What changed for the better:

|              | Before                               | Now                                                                     |
| ------------ | ------------------------------------ | ----------------------------------------------------------------------- |
| Layout       | Small pop-up over the app            | Full screen                                                             |
| Question     | "Are you trying to sign in?"         | "Approve this sign-in?" with "Only approve if you're trying to sign in" |
| Number entry | One text field                       | Separate boxes per digit, with a built-in keypad                        |
| Context      | App, location, and map as loose text | App and location grouped in one card beside the map                     |
| Buttons      | "No, it's not me" / "Yes"            | Deny / Approve, with Approve disabled until the number is entered       |

The redesign puts the context front and center instead of tucking it into a pop-up. Users can't approve until they've entered the number and the app and location sit right next to the decision.

The location comes from the sign-in's IP address, not the user's phone, and the text is shown at state-and-country level. VPNs, proxies, and mobile carriers can still place a sign-in somewhere unexpected. Tell users to treat a nearby spot on the map as normal and a different state or country as a red flag.

## Microsoft managed: leaving it to the Small Council

In the Authentication methods policy, some settings have three states instead of two: **Enabled**, **Disabled**, and **Microsoft managed**. In Graph, Microsoft managed shows up as `default`.

Microsoft managed means you're leaving the decision to the Small Council. Microsoft decides whether the feature is on and Microsoft can change that decision later as threats change. Like any council, they might act someday. Not today. It does **not** mean "on." Microsoft publishes what each Microsoft managed setting currently resolves to:

| Setting                                         | Microsoft managed currently means |
| ----------------------------------------------- | --------------------------------- |
| Application name in Authenticator notifications | Disabled                          |
| Location in Authenticator notifications         | Disabled                          |
| Report suspicious activity                      | Disabled                          |
| Registration campaign                           | Enabled                           |
| System-preferred authentication                 | Enabled                           |
| Authenticator Lite                              | Enabled                           |

So a tenant showing **Microsoft managed** for application name and location is running with additional context **off**. The portal doesn't make that obvious and that's where I see it slip through in assessments.

Microsoft says it may flip these to Enabled someday and will announce it in the Entra release notes. If you want additional context today, don't wait for that. Set it to **Enabled** yourself.

## Breaking out the wax: how to enable it

Additional context lives in the Microsoft Authenticator policy. Only users enabled for Authenticator in that policy can see it.

1. Sign in to the [Microsoft Entra admin center](https://entra.microsoft.com/?ref=guardians-of-kings-landing.ghost.io) as at least an **Authentication Policy Administrator**.
2. Go to **Entra ID > Authentication methods > Microsoft Authenticator**.
3. On the first tab, make sure Authenticator is enabled for your users. Set **Authentication mode** to **Any** (push and passwordless) or **Push** if you don't allow passwordless phone sign-in.
4. On the **Configure** tab, find **Show application name in push and passwordless notifications**. Change **Status** from Microsoft managed to **Enabled**, and set the target to **All users** or your pilot group.
5. Do the same for **Show geographic location in push and passwordless notifications**.
6. Select **Save**.

![2026-11-09_21-40-30.png](https://storage.ghost.io/c/bf/77/bf77821b-a321-4933-a591-722e54071e18/content/images/2026/11/2026-11-09_21-40-30.png)

A few rules to know:

- **Each setting takes one include group and one exclude group.** You can't stack several groups. Use a nested or dynamic group if you need more than one population.
- **Application name and location are separate.** You can turn on one without the other or exclude a group from just one. Some organizations exclude location for staff who travel constantly or work over VPN. My take: enable both, for all users. A slightly confusing location is a training problem. A missing one is a security problem.
- **Number matching isn't a setting anymore.** It's enforced for all Authenticator push notifications so you don't need to configure it here.

## Ask the Maesters: check the real settings with Microsoft Graph

The portal is the herald announcing what's selected. Graph is the Maester with the actual records. Graph tells you exactly what's stored, with no guessing about what "Microsoft managed" resolves to. It's also the fastest way to check a dozen client tenants without clicking through each one.

The setting lives in the Microsoft Authenticator method configuration:

```http
GET https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator

```

You need `Policy.Read.All` to read it. Changing it needs `Policy.ReadWrite.AuthenticationMethod`.

Look at `featureSettings` in the response:

```json
"featureSettings": {
  "displayAppInformationRequiredState": {
    "state": "default",
    "includeTarget": { "targetType": "group", "id": "all_users" },
    "excludeTarget": { "targetType": "group", "id": "00000000-0000-0000-0000-000000000000" }
  },
  "displayLocationInformationRequiredState": {
    "state": "default",
    "includeTarget": { "targetType": "group", "id": "all_users" },
    "excludeTarget": { "targetType": "group", "id": "00000000-0000-0000-0000-000000000000" }
  }
}

```

How to read it:

| Field                                   | What it tells you                                                         |
| --------------------------------------- | ------------------------------------------------------------------------- |
| displayAppInformationRequiredState      | Application name setting                                                  |
| displayLocationInformationRequiredState | Geographic location setting                                               |
| state                                   | enabled, disabled, or default (Microsoft managed, which is currently off) |
| includeTarget.id                        | all\_users or the object ID of the one included group                     |
| excludeTarget.id                        | The excluded group, or all zeros for none                                 |

If you see `default`, additional context is off for that tenant today. The ravens are flying unsealed.

One warning if you change it through Graph: Microsoft recommends a `GET` first, then sending the full configuration back in your `PATCH` with only these fields changed. A partial body can overwrite the rest of your Authenticator policy.

## Where the ravens still fly blind

- **Assuming Microsoft managed means on.** It's off for both settings today. Check every tenant you inherit.
- **Users outside the Authenticator policy.** Additional context only reaches users included in the Authenticator method policy. Anyone else sees nothing new.
- **NPS and AD FS.** Additional context isn't supported for Network Policy Server (the NPS extension for VPN and RADIUS) or AD FS. Those prompts stay bare.
- **Location isn't GPS.** It's based on the sign-in IP. VPNs, proxies, cloud egress, and carriers can make it look wrong. Train users on what "close enough" looks like before they start reporting every prompt.
- **Old Authenticator versions.** Microsoft blocks location-based Conditional Access sign-ins from older Authenticator versions and from phones with a spoofed location. Keep the app updated.
- **It's still push.** Additional context makes push MFA much harder to trick, but it isn't phishing-resistant. An adversary-in-the-middle proxy can still pass a real prompt through. Think of it as a solid legendary armor piece, not your exotic. Treat this as a strong bridge while you move users to passkeys, which I covered in [Forging Valyrian Steel](https://guardians-of-kings-landing.ghost.io/forging-valyrian-steel-your-post-sms-path-to-phishing-resistant-mfa/).

## The Guardian's checklist

- \[ \] Authenticator enabled in the Authentication methods policy for the users who should see context
- \[ \] Application name set to **Enabled**, not Microsoft managed
- \[ \] Geographic location set to **Enabled**, not Microsoft managed
- \[ \] Include and exclude groups confirmed (one of each per setting)
- \[ \] `featureSettings` verified through Graph shows `enabled`
- \[ \] Users told what the new prompt looks like and when to tap Deny
- \[ \] Report suspicious activity set to **Enabled** too, since it's also off under Microsoft managed

A raven with no seal could be from anyone. A raven with the sigil, the sender, and the castle it came from is one you can actually judge. Give your users that much before you ask them to open the gate.

And if the seal looks wrong? Deny it. Burn the letter. Eyes up, Guardians.

Thanks for reading. I appreciate every one of you who shows up for these posts. Got a story about a user who caught an attacker because the location looked wrong? Drop it in the comments and subscribe so you don't miss the next one.

Stay vigilant out there.

— Kevin