Sentinel Foundry - MCP Server (Github Community Release)
I’ve been cooking something that a lot of people in SOC have been struggling with — especially on the engineering side of Microsoft Sentinel. Thanks to the Microsoft Security team for shaping the capabilities of Sentinel even better with Sentinel Data Lake & Modern SecOps. Today’s the day I can finally share it. Note: This is not an official Microsoft product, but it is designed to make the Sentinel Build even better (complement) with much more intelligence. 🚀 Sentinel Foundry is now in public preview with 43 tools. (Sentinel Foundry - MCP Server) It’s an MCP server built to act like the brain of a strong Sentinel engineer — helping make building, improving, and operating Sentinel far more practical, faster, and honestly more enjoyable. For a lot of teams, the challenge is not understanding what Sentinel can do. The hard part is the engineering work around it: -> Deciding what data should actually be ingested -> Building a clean, scalable Sentinel foundation -> Writing useful detections instead of noisy ones -> Balancing security value with cost -> Turning ideas into deployable engineering outputs That is exactly why I built Sentinel Foundry to help communities grow stronger. It helps with the real engineering tasks behind Sentinel — from architecture thinking to detection design, deployment planning, ingestion strategy, automation ideas, and many of the workflows outlined in the GitHub project. How does it work? Here’s one of the flagship prompts I ran with it: “Give me a complete security posture report for our workspace. Score each pillar and tell me what to prioritise.” And within seconds, it produced a structured engineering blueprint that would normally take a lot longer to pull together manually. You can see the example prompts here in what it can do: https://github.com/prabhukiranveesam/Sentinel-Foundry#what-can-it-do I want building Sentinel to feel less like repetitive engineering overhead — and more like real security engineering that is fast, creative, and enjoyable. If you work with Sentinel as a SOC L2 analyst, engineer, detection engineer, consultant, or architect, I’d genuinely love for you to try it and tell me what you think. 🔗 Public Preview: https://github.com/prabhukiranveesam/Sentinel-Foundry This is just the start of an AI era — and I’m excited to keep shaping it with more powerful features over the coming days. This is very easy to set up and will be available to all of you at no cost during this month as part of the public preview, and your feedback is extremely valuable to shape this as a powerful solution.Unexpected button behaviour when using the prompt=create parameter in Entra External ID user flows
Hi, In a recent workload, I'm assisting a client to implement Entra External ID for streamlined authorization as well as single sign-on for associated registered external facing third-party applications for external customer users through their Entra External ID identity, as well as assisting the client with auth branding and other UI customizations, and preparing Entra ID federation custom OIDC providers and configuration for enabling SSO with organizational internal and remote work- and school accounts etc. The sign-up / create account experience is of importance to the client, as a rather substantial amount of users are expected to sign-up via self-service sign-up following having received an invite via another app. To ensure that the user lands on the create account view, in order to minimize the number of steps and actions the users need to take to get there, the prompt=create parameter is used to pre-select the sign-up/register experience in the user flows UI. Having stress-tested the user flows and experience recently, we noticed that in a specific scenario, some UI elements behave in a manner that could be described as unexpected, and even though a workaround has mitigated it to some extent, the behaviour of some elements could probably be improved a bit to ensure an even more consistent user experience in the built-in user flows. Specifically, if the user flow is invoked with the prompt parameter set, the user lands on the create account screen as expected, however, unless custom CSS modification is applied, the Back button that would typically be there, as if having arrived there from the initial sign-in screen where it’s also displayed. If pressing the Back button displayed on the Create account view when having navigated there with the prompt=create set in the /authorize request, pressing the button seemingly doesn’t have any impact or result in any action, one can click it, but nothing happens. I'd suspect it's perhaps a "remnant" from if the flow is invoked without any prompt parameter set, or with prompt=login set, but when prompt=create is set, there is no state/page history in the UI to navigate back to, as no previous page has been displayed or rendered yet and added to the history, and the Back button click thus doesn’t have any effect. In general, I think buttons that don't have any tangible action should not be displayed, also, if prompt=login is set, the Back button isn't shown then either on the very initial user flow view shown then, so it would seem the built-in user flows actually already follow such approach in fact, but not when the prompt=create has been set, thus causing some inconsistency in the UI that users could notice unless custom CSS styling is applied. The expected behaviour for our business case would be that if prompt=create is set, then, similar to the prompt=login, no Back button should be displayed, or, if shown, it should result in some navigation (perhaps something like javascript.go(-1), but that could/would be dependent on from where the user arrived, e.g., going back a step in the browser history won't work if the user clicked a link from an invite email ) and preferably not be non-actionable. Furthermore, on the topic of the Back button and its behaviour when the prompt=create parameter is set, there is another case at which we observed some unexpected button behaviour as well, that could probably benefit from some attention. At a specific second scenario, it seems that the Continue button is displayed without providing any action, and when clicking the Back button then, clicking it seemingly resets the "create account", state likely set by the prompt=create initially, and instead switches the flow back to the sign-in state, which can at least affect the display text of some subsequent buttons shown in later steps in the UI. The user arrives at a built-in Entra External ID user flow /authorize endpoint, with the prompt=create query parameter set The user triggers the OTP challenge by entering an email address to verify the email address The user receives the OTP code but enters it incorrectly, i.e., doesn't copy the full code length of eight digits, and instead enters/pastes six of the eight code digits. The UI then shows an error message that the code could not be used/validated, and the email address field is displayed again with the email address that was used for the verification attempt prefilled. If the user clicks the Continue button at this stage, nothing happens. If the user clicks the Back button instead (given that it’s not hidden), it shows the same view one more time, with the Back and Continue buttons at the bottom. However, if the user clicks the Continue button this time, it works and a new code is sent. On the next screen, where the newly sent code can be entered, instead of a button named "Continue", it will now instead show a button with the text "Sign-in" (it would seem like the create account state has gotten lost somewhere along the way at this point, perhaps when the back button in the step 5 above was pressed). If one omits the prompt=create parameter, or when using prompt=login, things seem to work fine, the above occurs when the prompt=create is set. The reason why is the prompt=create is used is due to a business requirement to try to minimize the steps, especially in conjunction with the registration/sign-up, as far a possible when signing up. We have opted for the built-in user flows, not the self-hosted native authentication UI pages, for this project, and then as I understand it, it is the prompt=create parameter that can/should be used to enable the user to land directly on the registration page without having to navigate there manually via the sign-up link, that is otherwise shown on the initial sign-in page. It would thus be great if the prompt=create parameter could have some attention (or perhaps if a dedicated sign-up user flow type could be added potentially, even though that would perhaps warrant some update to the user flow app linking as well, as my understanding is that one user flow can be linked to one app registration at a time currently) to avoid that some buttons become unresponsive when the parameter is used, or falls back to sign-in, to improve the built-in user flows further, as the prompt=create fulfils the business requirement well otherwise. If there would be any further/follow-up questions on the above, e.g., to clarify the requirement, or further explain the reproduction steps and behaviour observed, or anything else, please tell, and I'll ensure to get back as soon as possible. Also, would someone have some input on potential other/additional ways to pre-select the create account/sign-up experience, that would naturally be much appreciated as well, thanks! Regards KristofferDevice Code Flow: The Gift That Keeps on Giving — To Attackers
Tags: Microsoft Entra ID, Conditional Access, Device Code Flow, OAuth, Azure Arc, Azure Migrate, Identity Security, Zero Trust Introduction Device Code Flow was built for a good reason: helping users sign in on devices that cannot easily show a browser or accept a password. Smart TVs, consoles, kiosks, command-line tools, and headless systems all benefit from that design. But the same design that makes it convenient also creates a serious enterprise risk. Attackers can initiate the flow themselves, send the user a legitimate Microsoft sign-in URL and code, and receive valid tokens once the user completes authentication. No password theft. No fake login page. MFA may still succeed. From the identity platform’s point of view, the protocol worked exactly as designed. This post explains how Device Code Flow works, how it is abused in real attacks, why some Azure workflows still depend on it, and how administrators can reduce risk without treating it as a recommended authentication pattern for Azure services and tools. Allow Device Code Flow only for documented constrained scenarios. Everything else should move to Managed Identity, brokered interactive sign-in, or certificate-based Service Principal authentication. Let’s start with the version of Device Code Flow most people have already used, even if they did not know its name. You may have experienced this. At night, you’re in a hotel room after surviving back-to-back meetings, and you just want to relax and watch something mindless on Netflix. You grab the remote and navigate to the Netflix app on the room’s smart TV. Now you need to log in. You stare at the on-screen keyboard. It’s one of those alphabetical grids — not even QWERTY, which would be bad enough — and your password is something like C0llH0rs3@tt3ry&! because you read the right security blogs and you take this stuff seriously. You’re going to be clicking that remote for the next 10 minutes, and almost certainly making at least two typos. But then the TV does something clever. It shows you a short alphanumeric code — let’s say ABCD-1234 — and tells you: Go to netflix.com/activate on your phone or laptop, type in this code, and you’re done. Device Code Flow image So you do. You grab your phone, navigate to the URL, enter the code, authenticate normally (biometrics, password, MFA, whatever your setup requires), and within seconds — without touching that remote again — the TV lights up with your profile. This is defined in RFC 8628 — the OAuth 2.0 Device Authorization Grant, colloquially known as Device Code Flow. What’s Actually Happening Under the Hood Device Code Flow exists to solve a genuinely hard problem: some devices don’t have a practical way to run a full browser-based authentication experience. Smart TVs. Streaming sticks. Gaming consoles. IoT devices. CLI tools. Printers. The kind of hardware that has a network connection and a purpose, but whose input methods were clearly designed by someone who has never had to type an email address using a D-pad. Here’s the flow: The TV (the “device”) contacts the authorization server — in this case, the identity provider — and says, “Hey, I’d like to get an access token on behalf of a user, but I can’t do a full browser login. Help me out.” The authorization server responds with two things: a device code (a long, opaque string used internally) and a user code (that short, human-readable ABCD-1234 you saw on screen). It also provides a verification URI — the URL you go to on your other device. The TV starts polling. It repeatedly asks the authorization server, “Has the user authenticated yet? What about now? Now?” — at a defined interval, patiently waiting. You, on your trusted device, navigate to the verification URI, enter the user code, and complete a full, normal authentication flow — browser, password, MFA, the works. The authorization server connects the dots. It sees that the user code has been satisfied by an authenticated session, and the next time the TV polls, it gets back a shiny access token. The TV is now logged in. You watch your show. Everyone is happy. The authentication burden is shifted entirely to a device that can handle it — your phone, your laptop, something with a proper browser and a keyboard. The TV never sees your password. The TV never needs to. It just waits, politely, for the authorization server to say “yes, that user is who they say they are, and they consented to this.” Device Code Flow solves a real usability problem. It lets a constrained device complete sign-in through a second device that has a proper browser and keyboard. And it is being weaponized against your users right now. But What Happens When You’re the TV? Here’s where I need you to shift your mental model — because this is the pivot that makes Device Code Flow so dangerously exploitable. In the legitimate hotel TV scenario, you initiated the flow. You sat down in front of the TV. You opened Netflix. You decided you wanted to authenticate. The device code appeared because you asked for it, and the verification URI was presented in context, on a screen in a room you were physically occupying. Now imagine this instead: You receive a Teams message, or an email, or a LinkedIn DM from someone claiming to be from IT, or a vendor, or a colleague. They say they need you to help verify something, or access a shared resource, or complete an onboarding step. They send you a URL and a code. They ask you to go to — and here’s the thing — a completely legitimate Microsoft URL, enter the code, and sign in. The URL is real. The sign-in page is real. Your MFA prompt fires and you approve it, because you’re authenticating to a genuine Microsoft identity endpoint. Everything looks exactly like a normal authentication flow. Except you didn’t initiate it. An attacker did. The attacker has the same role as the TV in the legitimate scenario: it starts the device authorization request and waits for the authorization server to return tokens. When the victim completes the sign-in, those tokens go to the attacker-controlled session. No malware. No credential theft. No password phishing. Your MFA fired and you approved it. From the identity provider’s perspective, everything went exactly according to spec. You just authenticated someone else’s session. You were the TV. Welcome to Device Code Phishing. The Attackers Who Love Your TV (How Device Code Flow Was Weaponized) Remember that elegant, user-friendly device code flow we just finished praising? Turns out, the same properties that make it perfect for your Xbox also make it a gift-wrapped attack vector for threat actors. The absence of a browser on the authenticating device. The deliberate separation of code generation from authentication. The real Microsoft sign-in page that victims visit. Every single one of these “features” is a weapon in the right — or rather, wrong — hands. Let’s walk through exactly how this works, because the mechanics are genuinely diabolical in their simplicity. The Anatomy of a Device Code Phish Step one: The attacker initiates a device code flow. Not on some sketchy custom app — on a legitimate, trusted client application like Azure CLI, Microsoft Graph PowerShell, or even the Microsoft Teams client. They call the device authorization endpoint and receive back two things: a device_code (which stays server-side) and an user_code — that friendly eight-character alphanumeric string like FPQR7WXT . Step two: The attacker packages that user code into a phishing lure. An email. A Teams message. A LinkedIn DM. The lure is engineered to look like a legitimate IT notification, an MFA re-enrollment prompt, a SharePoint access request — anything that provides plausible context for why the recipient should navigate to microsoft.com/devicelogin and type in a code. Step three: The victim visits microsoft.com/devicelogin . This is the actual, legitimate Microsoft authentication endpoint. The victim enters the code, authenticates with their credentials, satisfies MFA, clicks Approve, and goes about their day feeling completely fine about what just happened. Step four: The attacker’s polling loop — which has been calling the token endpoint at the interval returned by the authorization server since step one — suddenly gets a 200 OK response. It receives a fully formed OAuth access token and may also receive a refresh token, depending on the client, scopes, tenant policy, and session controls. The attacker now has authenticated access to whatever Microsoft 365 services that token covers. No credentials were stolen. The user-facing authentication step may appear to originate from the victim’s normal device and location, while later token use may show different infrastructure depending on how the attacker operates. Microsoft Entra guidance treats Device Code Flow as a high-risk flow that should be blocked unless users have a documented need to sign in to shared or input-constrained devices. Storm-2372: When Nation-States Discovered the Phish This isn’t theoretical. A threat actor tracked as Storm-2372 operationalized device code phishing at scale against high-value targets. The Storm-2372 campaign followed the playbook described above — crafting contextually relevant lures delivered via email and messaging platforms, directing targets to the legitimate Microsoft device code authentication page, and harvesting the resulting tokens. Once armed with valid access tokens, and in some cases refresh tokens, the actors conducted reconnaissance across Microsoft 365 environments, accessed email, Teams conversations, SharePoint documents, and pivoted laterally through organizational infrastructure. Refresh tokens are particularly valuable when issued because they can be used to obtain new access tokens, subject to token lifetime, tenant policy, Conditional Access, Continuous Access Evaluation, revocation, sign-in risk, and downstream access patterns. AI in the Loop: Dynamic Code Generation and the 15-Minute Problem Device code flow has a natural defense built in: the user code expires after fifteen minutes. For manual phishing operations, this creates operational pressure — the attacker needs the victim to act quickly. The campaign solved this problem elegantly and unsettlingly. Using automation and AI-assisted tooling, the campaign deployed phishing pages capable of dynamic code generation. Rather than embedding a static user code in the phishing lure, the infrastructure generated fresh device codes on demand as victims interacted with the page. A victim who hesitated, navigated away, or took longer than expected to authenticate would receive a freshly generated, fully valid code — the fifteen-minute clock reset transparently in the background. The victim experienced a seamless interaction. The attacker maintained a continuously valid polling session. The campaign also employed role-aligned phishing lures — AI-generated pretexts tailored to the apparent role or organization of the target. An IT administrator received a message consistent with a service health alert. A finance employee received something that looked like an approval workflow notification. This contextual alignment dramatically increased conversion rates and reduced the likelihood of targets pausing to question the request. The result was compromise of organizational accounts at scale, with the automation layer removing the human operational bottleneck that had previously limited the throughput of device code phishing campaigns. Device Code Flow is not a new problem, but the risk has changed. Automation now makes these attacks easier to run at scale, and Conditional Access policies that ignore the flow leave a clean path for token theft. The Azure Reality: Security Guidance and Operational Constraints The Microsoft Entra guidance is clear: organizations should get as close as possible to a unilateral block on Device Code Flow, allowing it only in well-documented and secured use cases. In practical terms, Microsoft does not recommend Device Code Flow as the standard authentication pattern for Azure services, administration, automation, or onboarding workflows. The nuance is that some Azure tools still expose or require Device Code Flow in constrained situations: Server Core, Linux terminals, headless appliances, remote shells, and migration or onboarding workflows where a local browser is not available. That is a compatibility reality, not a security recommendation. The presence of a Device Code Flow path in a tool should be read as an exception mechanism, not as guidance to prefer it over Managed Identity, brokered interactive sign-in, or certificate-based Service Principal authentication. This is the Azure reality. Security guidance pushes administrators to block or tightly restrict Device Code Flow; some product workflows still need it in edge cases. The operational answer is not to normalize Device Code Flow across Azure, but to document the few cases that truly require it and move everything else to stronger identity primitives. Azure Arc-Enabled Servers: DCF in Constrained Onboarding Scenarios Let’s start with azcmagent connect , the command you run to onboard a server to Azure Arc-enabled servers. This is a core hybrid infrastructure workflow — the kind of thing organizations run at scale across hundreds or thousands of servers. The official CLI reference documentation notes that Device Code Flow is the authentication method for azcmagent connect on Windows Server Core editions and on Linux distributions. The reasoning is understandable: Server Core has no browser. Linux servers in an automated pipeline may have no interactive session at all. The arc agent needs some way to authenticate a human operator (or a service) during the initial onboarding handshake, and Device Code Flow conveniently sidesteps the need for a graphical environment. But “understandable” and “consistent with your Conditional Access policy” are two very different things. When a Conditional Access policy blocks the Device Code Flow grant type — which aligns with the recommended security posture for most tenants — infrastructure teams may see onboarding failures for Linux servers or Windows Server Core nodes unless they have planned an alternate authentication path. This creates a real operational tension between strong tenant-level controls and some constrained onboarding workflows. Azure Migrate: Known Registration Constraints Azure Migrate’s standard appliance-registration experience still depends on Device Code Flow. The appliance Configuration Manager requires an operator to copy a device code, open a browser-based Azure sign-in prompt, and authenticate with an Azure user account. As a result, a Conditional Access policy that blocks Device Code Flow for the registering user and relevant resources prevents the default registration path. Azure Migrate documentation identifies Device Code Flow restrictions as a common sign-in challenge and states that disabling DCF can block appliance registration. This is notable because our Entra guidance also recommends blocking Device Code Flow wherever possible, except for well-documented and secured use cases. Azure Migrate Official doc The alternative is not simply a Conditional Access exclusion or an additional user permission. It is a separate, certificate-based authentication model: an organization preconfigures a Microsoft Entra application and service principal, grants that principal Contributor access to the Azure Migrate project’s resource group, installs a certificate on the appliance, and completes registration using the application identity rather than an interactive user sign-in. This removes the user-context Device Code Flow dependency, but it does not remove the appliance-registration process itself. It also introduces operational overhead: the application is effectively dedicated to one appliance, its certificate must be protected and rotated, and the approach does not apply to the Azure Site Recovery replication appliance. Azure CLI and PowerShell: When DCF Appears as a Fallback The Azure CLI and Azure PowerShell modules are more nuanced cases because they support multiple authentication paths. Both tools prefer modern, platform-integrated authentication flows — browser-based interactive login, Integrated Windows Authentication, managed identity — when those options are available. The operative phrase is “when those options are available.” In headless environments, restricted execution contexts, containerized build agents with no browser dependency, or remote SSH sessions on machines that are not domain-joined, the preferred authentication hierarchy can become harder to use. In those cases, Device Code Flow may appear as a fallback when stronger approaches are not available or have not yet been implemented. For individual developers this may be a minor inconvenience. For enterprise teams running automated pipelines in tightly controlled environments, it can become a recurring source of breakage that traces back to the gap between DCF-blocking Conditional Access policies and workflows that still rely on DCF as an exception path. The Real-World Fallout: Exception Requests and Operational Friction Security-mature enterprises that implement tenant-level blocks on Device Code Flow can discover this tension through production failures. An infrastructure engineer attempts to onboard a batch of Azure Arc servers. The azcmagent connect command fails. A ticket is raised. The security team investigates. The root cause is identified: DCF is blocked, as intended, by policy. Now the organization has a decision to make: create a tightly scoped policy exception for the onboarding workflow, pre-provision service principal credentials and reconfigure the process, or pause the rollout while the right risk decision is made. None of those options is free. Each has security, operational, and ownership implications. This is where guidance, product behavior, and customer operations need clearer alignment. Until that alignment is complete, customers need a practical operating model: block DCF by default, document the constrained cases, and move repeatable workflows to stronger identity primitives wherever possible. The Clean Path Forward — A Five-Tier Authentication Hierarchy The Azure authentication model has a clear order of preference: use platform-managed identity where possible, use certificate-based service principals where you need external automation, and reserve Device Code Flow for cases where no stronger option is available. Here’s a five-tier decision framework for authenticating to Azure — ordered from preferred and durable to “only if you absolutely must.” This is also the practical interpretation of the guidance: Device Code Flow may exist in the toolbox, but it should sit at the bottom of the toolbox, not on the workbench. Tier 1: Managed Identity — The Gold Standard If your workload runs inside Azure — a virtual machine, an App Service, a Function App, an AKS workload using Microsoft Entra Workload ID, or an Azure Arc-enabled server — use the platform identity model wherever possible. There is no serious debate here. Managed Identity works by giving the Azure platform itself the responsibility of credential issuance and rotation. The workload requests a token from the Instance Metadata Service (IMDS) endpoint ( http://169.254.169.254/metadata/identity/oauth2/token ), and Azure handles everything behind the scenes: certificate lifecycle, token signing, rotation. You never see a secret. You never store a secret. There is no secret to leak, rotate, audit, or accidentally commit to a GitHub repository. System-assigned Managed Identities are scoped to the lifecycle of the resource itself — they live and die with the VM or service. User-assigned Managed Identities give you reuse across multiple resources and more fine-grained RBAC control. For Azure Arc-connected machines, the Arc agent provisions a Managed Identity backed by a locally managed certificate in a protected directory, giving even on-premises and multi-cloud workloads access to this same zero-secret model. The operational rule: if your code or process runs on a platform that supports Managed Identity, using anything else is a conscious downgrade that requires justification. Tier 2: Service Principal with Certificate — The Right Tool for Scale ManagedIdentity isn’t available for every scenario. If you’re building a CI/CD pipeline in GitHub Actions, running an onboarding script from an on-premises orchestration platform, or automating Azure Arc server registration at scale across thousands of machines, you need a Service Principal — and you should be using certificate-based authentication. Here’s why certificates are usually stronger than secrets in the Service Principal world: certificates are easier to govern through a managed issuance and rotation process, and they avoid long-lived shared strings being copied across scripts, repositories, and build systems. Microsoft Entra Conditional Access for workload identities can also apply to selected service principals, subject to licensing and feature scope, with controls such as location-based restrictions and risk-based blocking. That is not the same policy surface as user Conditional Access, and managed identities are not covered by those workload identity policies. For Azure Arc onboarding specifically, scope your Service Principal to the minimum viable role: Azure Connected Machine Onboarding . This built-in role grants exactly what the azcmagent connect process needs — nothing more. It cannot read your Key Vault secrets, enumerate your subscriptions, or touch your production workloads. Least privilege isn’t just a best practice checkbox here; it’s your blast radius control. Certificates should be issued from a managed PKI, stored in protected certificate stores (never in flat files on shared drives), and rotated on a defined schedule. Integrate certificate lifecycle management with your existing PKI or use Azure Key Vault-backed certificates where possible. Tier 3: Service Principal with Secret — The Acceptable Compromise Sometimes certificates are genuinely impractical. Legacy tooling, third-party integrations, or constrained environments may force your hand toward client secrets. This tier isn’t forbidden — but it carries an explicit operational contract. Client secrets must be treated with the same discipline as passwords: stored in secrets management systems (Azure Key Vault, HashiCorp Vault, your CI/CD platform’s native secrets store), never hard-coded, never logged, and rotated on a defined cadence. Microsoft Entra ID lets you set expiration periods — use them. Ninety-day rotation is a reasonable baseline; shorter is better for high-sensitivity workloads. Client secrets remain bearer credentials. If a secret is copied, an attacker can use it until it expires or is revoked, subject to workload identity controls and any other enforcement points in the environment. Tier 4: Interactive Browser / Brokered Authentication — For Human Admins When a human being is sitting at a keyboard performing administrative tasks — deploying resources, running az CLI commands, executing PowerShell modules against Azure Resource Manager — the right authentication pattern is interactive browser or brokered authentication. The Azure CLI ( az login ), Azure PowerShell ( Connect-AzAccount ), and the Azure Portal all support this flow. On modern Windows workstations with the Web Account Manager (WAM) broker enabled, authentication is handled through the broker, which integrates directly with Windows Hello, device compliance state, and Primary Refresh Token (PRT) infrastructure. This means your Conditional Access policies — require compliant device, require MFA, require specific named locations — all apply and are enforced at login time. This is authentication that knows who the user is, what device they’re on, and whether that device meets your security baseline. It’s the complete picture. Never suppress this flow with automation flags when a human is the actor. Tier 5: Device Code Flow — The Last Resort Device code flow ( az login --use-device-code , Connect-AzAccount -UseDeviceAuthentication ) should be treated as the last resort for Azure services and tools. It exists for a specific, narrow set of scenarios: headless Linux terminals, Windows Server Core deployments without a GUI, SSH sessions into remote systems where a browser genuinely cannot be launched, or constrained appliance and migration workflows where the product has no stronger supported option yet. In these cases, the operator signs in on a separate device and the initiating workload receives the token after authorization completes. That separation creates a control gap: Conditional Access evaluates the sign-in context of the device used for authentication, not necessarily the posture of the headless server, appliance, or remote shell that initiated the request. If you permit device code flow in your environment, do it deliberately: create a scoped Conditional Access exception, document the justification, and treat each use as a compliance event worth auditing. And ask yourself seriously whether Managed Identity or a Service Principal could solve the problem instead. Put plainly: if a workflow can use Managed Identity, brokered interactive authentication, or a certificate-based Service Principal, that is the route Microsoft customers should prefer. Device Code Flow is the exception path for constrained environments, not the recommended operating model for Azure. Quick Decision Table When in doubt, consult this table before typing a single auth flag: Scenario Recommended Pattern Avoid Azure VM / App Service System-assigned or user-assigned Managed Identity Service Principal with secret; Device Code Flow Azure Arc server process Managed Identity via the Azure Arc agent identity model Interactive login; hardcoded credentials Azure Arc onboarding at scale Service Principal with certificate and the Azure Connected Machine Onboarding role Service Principal with secret; Global Administrator credentials Azure Migrate registration Preconfigured Microsoft Entra application with certificate-based authentication Device Code Flow as the default path; over-privileged roles Human admin task Interactive browser or WAM brokered authentication with Conditional Access Shared service accounts; suppressed MFA Linux / Server Core / headless CLI Managed Identity where available, or Device Code Flow with a scoped Conditional Access exception Persistent CLI sessions with cached tokens and no expiry The hierarchy is deliberate. Every tier down represents a trade-off — more operational burden, less platform-enforced security, more human discipline required to compensate. The goal is to push as many of your workloads as possible to Tier 1, use Tier 2 for what Managed Identity can’t reach, and treat everything below that as a documented exception rather than a default pattern. Authentication choices are architectural decisions. Make them intentionally. Hardening Your Tenant — What Administrators Must Do Today (And Why Your Cloud Is Not a Hotel TV) The hardening work starts with visibility. Before blocking or allowing Device Code Flow, administrators need to know where it is already being used, which workflows depend on it, and which of those workflows can move to stronger authentication. Action 1: Inventory Current Usage — Find Where DCF Is Active Right Now You cannot harden what you cannot see. Start in Entra ID Sign-In Logs and filter for authentication protocol equals deviceCode . This will surface every user, application, and IP address currently relying on Device Code Flow across your tenant. Pay close attention to service accounts, unattended scripts, and any sign-ins originating from datacenter IP ranges — those are your highest-risk signals. If you haven’t already, flip your Conditional Access policies targeting DCF clients into report-only mode first. This gives you a real-world blast radius assessment before you enforce a block. Surprises in production are exciting exactly once. Action 2: Classify Every Use Case — Automation or Genuine Terminal Fallback? Not every Device Code Flow invocation is malicious, or even wrong. Walk through what you find in the logs and ask one honest question for each entry: Is this a human logging into a device with no keyboard, or is this a script pretending it has no other option? Genuine headless terminal scenarios — a shared kiosk, a network appliance with a PIN pad, a restricted industrial device — are legitimate. Everything else, especially recurring automated sign-ins from servers or pipelines, is a Service Principal waiting to be born. Action 3: Replace Repeatable Workflows With the Right Identity Primitive This is the most impactful action on the list. Every server onboarding script, appliance registration routine, and CI/CD pipeline that currently uses Device Code Flow should be migrated to one of two things: Managed Identities — for anything running inside Azure. Zero credentials. No rotation. No excuses. Certificate-based Service Principals — for workloads running outside Azure where Managed Identity isn’t available. Certificates are auditable, rotatable, and are not susceptible to this specific device-code phishing pattern. If a team finds that migration difficult, treat it as an implementation gap to close, not as a reason to keep a weaker authentication pattern in place. Action 4: Scoped Exceptions Only — No Tenant-Wide Free Passes If you must allow Device Code Flow for a specific use case after completing Actions 1 through 3, then scope it surgically. Target specific named users, restrict to compliant or named network locations, and limit to the exact application that requires it. Attach strict sign-in monitoring alerts so that any deviation from the expected pattern pages someone immediately. Granting tenant-wide exceptions because one team has a legacy appliance is the organizational equivalent of leaving the front door of your office building unlocked because the mailroom needs early access. Scope it. Monitor it. Review it quarterly. Action 5: Improve Error Clarity — Make Failures Actionable When Device Code Flow is blocked by a Conditional Access policy, the error experience can be difficult for operators to act on. If the message is opaque, teams either open a ticket without enough context or look for a workaround. Neither outcome helps the customer. Internal scripts and tooling should catch Conditional Access block errors and surface clear, prescriptive guidance. Suggested runtime error wording: “Device Code Flow authentication was blocked by your organization’s security policy. This workflow requires an identity with delegated permissions in an interactive session. For automated workloads, use a Managed Identity or a Service Principal with certificate-based authentication. Contact your identity platform team for migration assistance.” For product and documentation improvements, language like the following would help customers make safer choices: “Device Code Flow (RFC 8628) is designed for input-constrained devices such as smart TVs and kiosks. It is not recommended for automated scripts, CI/CD pipelines, or server-side processes. For unattended authentication scenarios, use Managed Identities for Azure-hosted workloads or certificate-based Service Principals for external workloads. Enabling Device Code Flow in enterprise environments without Conditional Access restrictions significantly increases phishing risk.” Clear documentation prevents the next engineer from making the same mistake and helps customers choose the right authentication pattern earlier. The Hotel TV — A Final Word Let’s go back to where we started: you, in a hotel room, staring at a television that doesn’t have a keyboard, trying to log into Netflix. You pull out your phone, navigate to a short URL, type an eight-character code, and thirty seconds later you’re watching something you’ll regret staying up for. It is, genuinely, a delightful piece of user experience engineering. RFC 8628 solved a real problem elegantly, and for that use case — a constrained device, a human present in the room, a low-stakes personal account — Device Code Flow is perfectly appropriate. The problem is not Device Code Flow. The problem is transplanting a mechanism designed for hotel televisions into environments where a compromised token can exfiltrate production databases, pivot across subscriptions, and trigger regulatory breach notifications at three in the morning. Your enterprise Azure tenant is not a hotel TV. The stakes are not whether someone watches an extra episode before sleep. The stakes are your customers’ data, your company’s reputation, and in regulated industries, your legal exposure. Authentication mechanisms must be matched to the environment they protect — and an environment with that much at risk deserves better than a flow designed for leisure viewing. Block Device Code Flow by default. Do not recommend it as the normal way to use Azure services or tools. Migrate automation to proper identity primitives. Grant exceptions only where the use case genuinely demands it, and monitor them relentlessly. The elegance of the original protocol is not a reason to leave the door open. It is simply a reason to appreciate it on the television where it belongs — while you protect everything else with something far more serious.
Exciting Announcements: New Data Connectors Released Using the Codeless Connector Framework
Microsoft Sentinel’s Codeless Connector Framework or ‘CCF’ (formerly called Codeless Connector Platform [CCP]) represents a paradigm shift in data ingestion, making it easier than ever for organisations to do more with Microsoft Sentinel by integrating diverse data sources seamlessly. Designed to simplify and expedite the onboarding of data sources, CCF eliminates the need for extensive coding expertise and maintaining additional services to facilitate ingestion, allowing security teams to focus on what truly matters – safeguarding their environment. Advantages of the Codeless Connector Framework The Codeless Connector Framework offers several compelling benefits: Ease of Use: CCF configuration-based templates allows advanced users to create data connectors without writing exhausting code, making the onboarding process quicker and more accessible to a broader audience. Flexibility: Users can customise data streams to meet their specific needs; optimizing efficacy while ensuring more control on the data being ingested. Scalability: The connectors built using CCF follows a true SaaS auto-expansion model making them highly scalable and natively reliable for large data volumes. Efficiency: By reducing the time and effort required to develop and deploy data connectors, CCF accelerates the availability of critical insights for security monitoring and more rapidly expands the value Microsoft Sentinel provides. What are we up to? We recognize that Codeless Connectors offer substantial advantages over Azure Function App based ingestion in Microsoft Sentinel in most cases. That motivates us to continue investing in modernizing our ingestion patterns for out-of-box connectors; one connector at a time. Another goal of modernizing these connectors is to replace the deprecated HTTP Data Collector API with the Log Ingestion API to send data to Microsoft Sentinel. Announcing the General Availability of New Data Connectors We are continually improving the Data Collection experience for our customers and are thrilled to announce that the following data connectors are now Generally Available (GA) on the Codeless Connector Framework. Atlassian Confluence Ingesting Confluence audit logs allows organizations to monitor collaboration activity, detect security risks, and troubleshoot configuration issues using Confluence audit records. Auth0 With the Auth0 Connector, organizations can effortlessly integrate authentication and authorization data from Auth0 into Microsoft Sentinel. This connector provides valuable insights into user activities and access patterns, bolstering identity security and compliance efforts. Azure DevOps Audit logs from Azure DevOps, allows security teams to monitor user activities, detect anomalous behavior, and investigate potential threats across DevOps environments. Box The Box Connector facilitates the ingestion of file storage and sharing data from Box into Microsoft Sentinel. By leveraging this connector, security teams can monitor file access and sharing activities, ensuring data integrity, and preventing unauthorized access. Google Cloud Platform Load Balancer With GCP Load Balancer and Web Application Firewall (Cloud Armor) logs, security teams can monitor inbound network activity, enforce security policies, and detect threats across GCP environments. Proofpoint POD The ingestion of email security logs allows organizations to monitor message traceability, detect threats, and investigate data exfiltration attempts by attackers and malicious insiders. Proofpoint TAP Email threat intelligence logs, including message and click events, provides visibility into malware and phishing activity to support custom alerts, dashboards, and threat investigation. SentinelOne The SentinelOne Connector enables seamless ingestion of threat intelligence and endpoint security data from SentinelOne into Microsoft Sentinel. This integration empowers security teams to enhance their threat detection capabilities and respond swiftly to potential threats. New Connectors in Public Preview CrowdStrike Falcon Data Replicator (S3 based Polling) Google Cloud Platform VPC Flow Google Cloud Platform DNS Google IAM These new additions are not new out-of-box sources in Microsoft Sentinel, but they do improve how data is collected. The previously Azure Function App based polling has now been upgraded to the Codeless Connector Framework for these products to ensure data collection adheres to the more scalable; advantageous pattern with CCF. As noted previously, the newer version of these connectors replaces the deprecated HTTP Data Collector API with the Log Ingestion API to send data to Microsoft Sentinel. Call to Action! Microsoft Sentinel customers collecting data from any of the mentioned sources using Azure Function Apps are advised to migrate their ingestion streams to newer versions to utilize the Codeless Connector Framework. While we continue to improve the data collection experience across all connectors, we encourage our customers and partners to join the Microsoft Security Communities to benefit from early insights about the latest and greatest with Microsoft Security. Call to Action for ISV Partners We invite our ISV partners to migrate their Azure Function App-based data connectors to the Codeless Connector Framework. By leveraging CCF for data ingestion, we can ensure that our mutual customers benefit from streamlined data integration and enhanced security monitoring in Microsoft Sentinel. We are committed to ensuring partners have all the support needed in this transformation. For any support, please reach out to us at Microsoft Sentinel Partners. Join us in this transformative journey to empower our customers by unlocking the full potential of their security investments with Microsoft Sentinel’s Codeless Connector Framework. References Create a codeless connector for Microsoft Sentinel Migrate from the HTTP Data Collector API to the Log Ingestion API to send data to Azure Monitor Logs
Making AI Apps Enterprise-Ready with Microsoft Purview and Microsoft Foundry
Building AI apps is easy. Shipping them to production is not. Microsoft Foundry lets developers bring powerful AI apps and agents to production in days. But managing safety, security, and compliance for each one quickly becomes the real bottleneck. Every enterprise AI project hits the same wall: security reviews, data classification, audit trails, DLP policies, retention requirements. Teams spend months building custom logging pipelines and governance systems that never quite keep up with the app itself. There is a faster way. Enable Purview & Ship Faster! Microsoft Foundry now includes native integration with Microsoft Purview. When you enable it, every AI interaction in your subscription flows into the same enterprise data governance infrastructure that already protects your Microsoft 365 and Azure data estate. No SDK changes. No custom middleware. No separate audit system to maintain. Here is what you get: Visibility within 24 hours. Data Security Posture Management (DSPM) shows you total interactions, sensitive data detected in prompts and responses, user activity across AI apps, and insider risk scoring. This dashboard exists the moment you flip the toggle. Automatic data classification. The same classification engine that scans your Microsoft 365 tenant now scans AI interactions. Credit card numbers, health information, SSNs, and your custom sensitive information types are all detected automatically. Audit logs you do not have to build. Every AI interaction is logged in the Purview unified audit log. Timestamps, user identity, the AI app involved, files accessed, sensitivity labels applied. When legal needs six months of AI interactions for an investigation, the data is already there. DLP policy enforcement. Configure policies that block prompts containing sensitive information before they reach the model. This uses the same DLP framework you already know. eDiscovery, retention, and communication compliance. Search AI interactions alongside email and Teams messages. Set retention policies by selecting "Enterprise AI apps" as the location. Detect harmful or unauthorized content in prompts. How to Enable Prerequisite: You need the “Azure AI Account Owner” role assigned by your Subscription Owner. Open the Microsoft Foundry portal (make sure you are in the new portal) Select Operate from the top navigation Select Compliance in the left pane Select the Security posture tab Select the Azure Subscription Enable the toggle next to Microsoft Purview Repeat the above steps for other subscriptions By enabling this toggle, data exchanged within Foundry apps and agents' starts flowing to Purview immediately. Purview reports populate within 24 hours. What shows up in Purview? Purview Data Security Admins: Go to the Microsoft Purview portal, open DSPM, and follow the recommendation to setup “Secure interactions from enterprise AI apps” . Navigate to DSPM > Discover > Apps and Agents to review and monitor the Foundry apps built in your organization Navigate to DSPM > Activity Explorer to review the activity on a given agent/application What About Cost? Enabling the integration is free. Audit Standard is included for Foundry apps. You will only be charged for data security policies you setup for governing Foundry data. A Real-World Scenario: The Internal HR Assistant Consider a healthcare company building an internal AI agent for HR questions. The Old Way: The developer team spends six weeks building a custom logging solution to strip PII/PHI from prompts to meet HIPAA requirements. They have to manually demonstrate these logs to compliance before launch. The Foundry Way: The team enables the Purview toggle. Detection: Purview automatically flags if an employee pastes a patient ID into the chat. Retention: The team selects "Enterprise AI Apps" in their retention policy, ensuring all chats are kept for the required legal period. Outcome: The app ships on schedule because Compliance trusts the controls are inherited, not bolted on. Takeaway Microsoft Purview DSPM is a gamechanger for organizations looking to adopt AI responsibly. By integrating with Microsoft Foundry, it provides a comprehensive framework to discover, protect, and govern AI interactions ensuring compliance, reducing risk, and enabling secure innovation. We built this integration because teams kept spending months on compliance controls that already exist in Microsoft's stack. The toggle is there. The capabilities are real. Your security team already trusts Purview. Your compliance team already knows the tools. Enable it. Ship your agent. Let the infrastructure do what infrastructure does best: work in the background while you focus on what your application does. Additional Resources Documentation: Use Microsoft Purview to manage data security & compliance for Microsoft Foundry | Microsoft LearnAuthenticating AWS Workloads to Azure Functions using Workload Identity Federation
Step-by-step guide to configuring Workload Identity Federation between AWS and Azure, enabling service-to-service authentication where AWS workloads can securely call Azure Functions using token-based access instead of stored credentials.Kerberos and the End of RC4: Protocol Hardening and Preparing for CVE‑2026‑20833
CVE-2026-20833 addresses the continued use of the RC4‑HMAC algorithm within the Kerberos protocol in Active Directory environments. Although RC4 has been retained for many years for compatibility with legacy systems, it is now considered cryptographically weak and unsuitable for modern authentication scenarios. As part of the security evolution of Kerberos, Microsoft has initiated a process of progressive protocol hardening, whose objective is to eliminate RC4 as an implicit fallback, establishing AES128 and AES256 as the default and recommended algorithms. This change should not be treated as optional or merely preventive. It represents a structural change in Kerberos behavior that will be progressively enforced through Windows security updates, culminating in a model where RC4 will no longer be implicitly accepted by the KDC. If Active Directory environments maintain service accounts, applications, or systems dependent on RC4, authentication failures may occur after the application of the updates planned for 2026, especially during the enforcement phases introduced starting in April and finalized in July 2026. For this reason, it is essential that organizations proactively identify and eliminate RC4 dependencies, ensuring that accounts, services, and applications are properly configured to use AES128 or AES256 before the definitive changes to Kerberos protocol behavior take effect. Official Microsoft References CVE-2026-25177 - Security Update Guide - Microsoft - Active Directory Domain Services Elevation of Privilege Vulnerability Microsoft Support – How to manage Kerberos KDC usage of RC4 for service account ticket issuance changes related to CVE-2026-20833 (KB 5073381) Microsoft Learn – Detect and Remediate RC4 Usage in Kerberos AskDS – What is going on with RC4 in Kerberos? Beyond RC4 for Windows authentication | Microsoft Windows Server Blog So, you think you’re ready for enforcing AES for Kerberos? | Microsoft Community Hub Risk Associated with the Vulnerability When RC4 is used in Kerberos tickets, an authenticated attacker can request Service Tickets (TGS) for valid SPNs, capture these tickets, and perform offline brute-force attacks, particularly Kerberoasting scenarios, with the goal of recovering service account passwords. Compared to AES, RC4 allows significantly faster cracking, especially for older accounts or accounts with weak passwords. Technical Overview of the Exploitation In simplified terms, the exploitation flow occurs as follows: The attacker requests a TGS for a valid SPN. The KDC issues the ticket using RC4, when that algorithm is still accepted. The ticket is captured and analyzed offline. The service account password is recovered. The compromised account is used for lateral movement or privilege escalation. Official Timeline Defined by Microsoft Important clarification on enforcement behavior Explicit account encryption type configurations continue to be honored even during enforcement mode. The Kerberos hardening associated with CVE‑2026‑20833 focuses on changing the default behavior of the KDC, enforcing AES-only encryption for TGS ticket issuance when no explicit configuration exists. This approach follows the same enforcement model previously applied to Kerberos session keys in earlier security updates (for example, KB5021131 related to CVE‑2022‑37966), representing another step in the progressive removal of RC4 as an implicit fallback. January 2026 – Audit Phase Starting in January 2026, Microsoft initiated the Audit Phase related to changes in RC4 usage within Kerberos, as described in the official guidance associated with CVE-2026-20833. The primary objective of this phase is to allow organizations to identify existing RC4 dependencies before enforcement changes are applied in later phases. During this phase, no functional breakage is expected, as RC4 is still permitted by the KDC. However, additional auditing mechanisms were introduced, providing greater visibility into how Kerberos tickets are issued in the environment. Analysis is primarily based on the following events recorded in the Security Log of Domain Controllers: Event ID 4768 – Kerberos Authentication Service (AS request / Ticket Granting Ticket) Event ID 4769 – Kerberos Service Ticket Operations (Ticket Granting Service – TGS) Additional events related to the KDCSVC service These events allow identification of: the account that requested authentication the requested service or SPN the source host of the request the encryption algorithm used for the ticket and session key This information is critical for detecting scenarios where RC4 is still being implicitly used, enabling operations teams to plan remediation ahead of the enforcement phase. If these events are not being logged on Domain Controllers, it is necessary to verify whether Kerberos auditing is properly enabled. For Kerberos authentication events to be recorded in the Security Log, the corresponding audit policies must be configured. The minimum recommended configuration is to enable Success auditing for the following subcategories: Kerberos Authentication Service Kerberos Service Ticket Operations Verification can be performed directly on a Domain Controller using the following commands: auditpol /get /subcategory:"Kerberos Service Ticket Operations" auditpol /get /subcategory:"Kerberos Authentication Service" In enterprise environments, the recommended approach is to apply this configuration via Group Policy, ensuring consistency across all Domain Controllers. The corresponding policy can be found at: Computer Configuration - Policies - Windows Settings - Security Settings - Advanced Audit Policy Configuration - Audit Policies - Account Logon Once enabled, these audits record events 4768 and 4769 in the Domain Controllers’ Security Log, allowing analysis tools—such as inventory scripts or SIEM/Log Analytics queries—to accurately identify where RC4 is still present in the Kerberos authentication flow. April 2026 – Enforcement with Manual Rollback With the April 2026 update, the KDC begins operating in AES-only mode (0x18) when the msDS-SupportedEncryptionTypes attribute is not defined. This means RC4 is no longer accepted as an implicit fallback. During this phase, applications, accounts, or computers that still implicitly depend on RC4 may start failing. Manual rollback remains possible via explicit configuration of the attribute in Active Directory. July 2026 – Final Enforcement Starting in July 2026, audit mode and rollback options are removed. RC4 will only function if explicitly configured—a practice that is strongly discouraged. This represents the point of no return in the hardening process. Official Monitoring Approach Microsoft provides official scripts in the repository: https://github.com/microsoft/Kerberos-Crypto/tree/main/scripts The two primary scripts used in this analysis are: Get-KerbEncryptionUsage.ps1 The Get-KerbEncryptionUsage.ps1 script, provided by Microsoft in the Kerberos‑Crypto repository, is designed to identify how Kerberos tickets are issued in the environment by analyzing authentication events recorded on Domain Controllers. Data collection is primarily based on: Event ID 4768 – Kerberos Authentication Service (AS‑REQ / TGT issuance) Event ID 4769 – Kerberos Service Ticket Operations (TGS issuance) From these events, the script extracts and consolidates several relevant fields for authentication flow analysis: Time – when the authentication occurred Requestor – IP address or host that initiated the request Source – account that requested the ticket Target – requested service or SPN Type – operation type (AS or TGS) Ticket – algorithm used to encrypt the ticket SessionKey – algorithm used to protect the session key Based on these fields, it becomes possible to objectively identify which algorithms are being used in the environment, both for ticket issuance and session establishment. This visibility is essential for detecting RC4 dependencies in the Kerberos authentication flow, enabling precise identification of which clients, services, or accounts still rely on this legacy algorithm. Example usage: .\Get-KerbEncryptionUsage.ps1 -Encryption RC4 -Searchscope AllKdcs | Export-Csv -Path .\KerbUsage_RC4_All_ThisDC.csv -NoTypeInformation -Encoding UTF8 Data Consolidation and Analysis In enterprise environments, where event volumes may be high, it is recommended to consolidate script results into analytical tools such as Power BI to facilitate visualization and investigation. The presented image illustrates an example dashboard built from collected results, enabling visibility into: Total events analyzed Number of Domain Controllers involved Number of requesting clients (Requestors) Most frequently involved services or SPNs (Targets) Temporal distribution of events RC4 usage scenarios (Ticket, SessionKey, or both) This type of visualization enables rapid identification of RC4 usage patterns, remediation prioritization, and progress tracking as dependencies are eliminated. Additionally, dashboards help answer key operational questions, such as: Which services still depend on RC4 Which clients are negotiating RC4 for sessions Which Domain Controllers are issuing these tickets Whether RC4 usage is decreasing over time This combined automated collection + analytical visualization approach is the recommended strategy to prepare environments for the Microsoft changes related to CVE‑2026‑20833 and the progressive removal of RC4 in Kerberos. Visualizing Results with Power BI To facilitate analysis and monitoring of RC4 usage in Kerberos, it is recommended to consolidate script results into a Power BI analytical dashboard. 1. Install Power BI Desktop Download and install Power BI Desktop from the official Microsoft website 2. Execute data collection After running the Get-KerbEncryptionUsage.ps1 script, save the generated CSV file to the following directory: C:\Temp\Kerberos_KDC_usage_of_RC4_Logs\KerbEncryptionUsage_RC4.csv 3. Open the dashboard in Power BI Open the file RC4-KerbEncryptionUsage-Dashboards.pbix using Power BI Desktop. If you are interested, please leave a comment on this post with your email address, and I will be happy to share with you. 4. Update the data source If the CSV file is located in a different directory, it will be necessary to adjust the data source path in Power BI. As illustrated, the dashboard uses a parameter named CsvFilePath, which defines the path to the collected CSV file. To adjust it: Open Transform Data in Power BI. Locate the CsvFilePath parameter in the list of Queries. Update the value to the directory where the CSV file was saved. Click Refresh Preview or Refresh to update the data. Click Home → Close & Apply. This approach allows rapid identification of RC4 dependencies, prioritization of remediation actions, and tracking of progress throughout the elimination process. List-AccountKeys.ps1 This script is used to identify which long-term keys are present on user, computer, and service accounts, enabling verification of whether RC4 is still required or whether AES128/AES256 keys are already available. Interpreting Observed Scenarios Microsoft recommends analyzing RC4 usage by jointly considering two key fields present in Kerberos events: Ticket Encryption Type Session Encryption Type Each combination represents a distinct Kerberos behavior, indicating the source of the issue, risk level, and remediation point in the environment. In addition to events 4768 and 4769, updates released starting January 13, 2026, introduce new Kdcsvc events in the System Event Log that assist in identifying RC4 dependencies ahead of enforcement. These events include: Event ID 201 – RC4 usage detected because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined. Event ID 202 – RC4 usage detected because the service account does not have AES keys and the msDS-SupportedEncryptionTypes attribute is not defined. Event ID 203 – RC4 usage blocked (enforcement phase) because the client advertises only RC4 and the service does not have msDS-SupportedEncryptionTypes defined. Event ID 204 – RC4 usage blocked (enforcement phase) because the service account does not have AES keys and msDS-SupportedEncryptionTypes is not defined. Event ID 205 – Detection of explicit enablement of insecure algorithms (such as RC4) in the domain policy DefaultDomainSupportedEncTypes. Event ID 206 – RC4 usage detected because the service accepts only AES, but the client does not advertise AES support. Event ID 207 – RC4 usage detected because the service is configured for AES, but the service account does not have AES keys. Event ID 208 – RC4 usage blocked (enforcement phase) because the service accepts only AES and the client does not advertise AES support. Event ID 209 – RC4 usage blocked (enforcement phase) because the service accepts only AES, but the service account does not have AES keys. https://support.microsoft.com/en-gb/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc They indicate situations where RC4 usage will be blocked in future phases, allowing early detection of configuration issues in clients, services, or accounts. These events are logged under: Log: System Source: Kdcsvc Below are the primary scenarios observed during the analysis of Kerberos authentication behavior, highlighting how RC4 usage manifests across different ticket and session encryption combinations. Each scenario represents a distinct risk profile and indicates specific remediation actions required to ensure compliance with the upcoming enforcement phases. Scenario A – RC4 / RC4 In this scenario, both the Kerberos ticket and the session key are issued using RC4. This is the worst possible scenario from a security and compatibility perspective, as it indicates full and explicit dependence on RC4 in the authentication flow. This condition significantly increases exposure to Kerberoasting attacks, since RC4‑encrypted tickets can be subjected to offline brute-force attacks to recover service account passwords. In addition, environments remaining in this state have a high probability of authentication failure after the April 2026 updates, when RC4 will no longer be accepted as an implicit fallback by the KDC. Events Associated with This Scenario During the Audit Phase, this scenario is typically associated with: Event ID 201 – Kdcsvc Indicates that: the client advertises only RC4 the service does not have msDS-SupportedEncryptionTypes defined the Domain Controller does not have DefaultDomainSupportedEncTypes defined This means RC4 is being used implicitly. This event indicates that the authentication will fail during the enforcement phase. Event ID 202 – Kdcsvc Indicates that: the service account does not have AES keys the service does not have msDS-SupportedEncryptionTypes defined This typically occurs when: legacy accounts have never had their passwords reset only RC4 keys exist in Active Directory Possible Causes Common causes include: the originating client (Requestor) advertises only RC4 the target service (Target) is not explicitly configured to support AES the account has only legacy RC4 keys the msDS-SupportedEncryptionTypes attribute is not defined Recommended Actions To remediate this scenario: Correctly identify the object involved in the authentication flow, typically: a service account (SPN) a computer account or a Domain Controller computer object Verify whether the object has AES keys available using analysis tools or scripts such as List-AccountKeys.ps1. If AES keys are not present, reset the account password, forcing generation of modern cryptographic keys (AES128 and AES256). Explicitly define the msDS-SupportedEncryptionTypes attribute to enable AES support. Recommended value for modern environments: 0x18 (AES128 + AES256) = 24 As illustrated below, this configuration can be applied directly to the msDS-SupportedEncryptionTypes attribute in Active Directory. AES can also be enabled via Active Directory Users and Computers by explicitly selecting: This account supports Kerberos AES 128 bit encryption This account supports Kerberos AES 256 bit encryption These options ensure that new Kerberos tickets are issued using AES algorithms instead of RC4. Temporary RC4 Usage (Controlled Rollback) In transitional scenarios—during migration or troubleshooting—it may be acceptable to temporarily use: 0x1C (RC4 + AES) = 28 This configuration allows the object to accept both RC4 and AES simultaneously, functioning as a controlled rollback while legacy dependencies are identified and corrected. However, the final objective must be to fully eliminate RC4 before the final enforcement phase in July 2026, ensuring the environment operates exclusively with AES128 and AES256. Scenario B – AES / RC4 In this case, the ticket is protected with AES, but the session is still negotiated using RC4. This typically indicates a client limitation, legacy configuration, or restricted advertisement of supported algorithms. Events Associated with This Scenario During the Audit Phase, this scenario may generate: Event ID 206 Indicates that: the service accepts only AES the client does not advertise AES in the Advertised Etypes In this case, the client is the issue. Recommended Action Investigate the Requestor Validate operating system, client type, and advertised algorithms Review legacy GPOs, hardening configurations, or settings that still force RC4 For Linux clients or third‑party applications, review krb5.conf, keytabs, and Kerberos libraries Scenario C – RC4 / AES Here, the session already uses AES, but the ticket is still issued using RC4. This indicates an implicit RC4 dependency on the Target or KDC side, and the environment may fail once enforcement begins. Events Associated with This Scenario This scenario may generate: Event ID 205 Indicates that the domain has explicit insecure algorithm configuration in: DefaultDomainSupportedEncTypes This means RC4 is explicitly allowed at the domain level. Recommended Action Correct the Target object Explicitly define msDS-SupportedEncryptionTypes with 0x18 = 24 Revalidate new ticket issuance to confirm full migration to AES / AES Conclusion CVE‑2026‑20833 represents a structural change in Kerberos behavior within Active Directory environments. Proper monitoring is essential before April 2026, and the msDS-SupportedEncryptionTypes attribute becomes the primary control point for service accounts, computer accounts, and Domain Controllers. July 2026 represents the final enforcement point, after which there will be no implicit rollback to RC4.
Microsoft Leads a New Era of Software Supply Chain Transparency
Today, Microsoft announces the general availability of Microsoft’s Signing Transparency (MST) – a first-of-its-kind capability that brings unprecedented visibility and trust to our software supply chain. With this release, Microsoft is leading the industry by recording the build of critical cloud services into a publicly readable and verifiable SCITT standard (Supply Chain Integrity, Transparency, and Trust) compliant blockchain ledger. This means every production software build for in scope services like Azure Attestation and Azure Managed HSM (Hardware Security Module), Azure confidential ledger, Microsoft Signing Transparency itself (and others over time) – is now logged in an immutable, tamper-evident record. Only builds that are in the MST ledger are deployed to production; this gives customers confidence that the supply chain for these critical services can be audited at anytime. Notably, the MST ledger is fully open source and built to align with the emerging IETF SCITT standard. By embracing SCITT’s principles and open protocols, Microsoft ensures that MST not only secures our own ecosystem but also contributes to a broader industry movement toward standardized supply chain transparency. The open-source MST ledger serves as a verifiable trust anchor that any organization or researcher can inspect, audit, or even integrate with their own tooling. MST itself meets the highest levels of transparency, backed by a tamper-proof confidential ledger, open-source, and independently verified. Specifically, we are making the foundation of our trust model transparent and accessible to everyone – reinforcing that trust must be earned through proof, not just promises. This launch marks a major milestone in our commitment to Zero Trust principles, extending “never trust, always verify” all the way into the build itself. Building on a public preview introduced late last year, MST’s general availability delivers verifiable transparency at the software level. It transforms traditional code signing with an additive trust layer that is accessible via an open verification model. Every new software update is accompanied by a publicly auditable proof of integrity, enabling security teams to proactively confirm that each update is authentic and unaltered. To help organizations get the most out of this capability, we are also introducing a free tool to explore the contents – Ledger Explorer – an offline tool that allows security teams to examine MST ledger entries, verify cryptographic proofs, and even validate the ledger’s integrity independently. This tool, combined with MST’s open design, ensures that every Microsoft customer – and the broader community – can hold us accountable in real time for the software we run on their behalf. Key Benefits of Microsoft’s Signing Transparency (MST) Verified Code Integrity – Every software release is cryptographically logged in MST’s ledgers. This makes each build tamper-evident and traceable. If an attacker attempts to inject malicious code or sign an unauthorized update, it will be evident through the well-defined validation step built into the SCITT standard. Organizations gain the assurance that code integrity can be independently confirmed at any time. Independent Verification & Zero Trust – MST enables customers and auditors to verify software authenticity on their own, without having to solely rely on vendor attestations. For each update, Microsoft provides a transparency “receipt” (proof of logging) that you can use to prove the update was officially published and unaltered. This fosters a “don’t just trust, verify” approach, empowering security teams to double-check everything running in their environment aligns with what Microsoft intended. Audit-Trail & Compliance – The transparency ledger creates a permanent, auditable timeline of code deployments. Every entry is a record of what was released and when, backed by cryptographic proofs. This simplifies compliance reporting and accelerates forensic analysis. In the event of an incident, you can quickly audit the ledger to see if any unexpected code was introduced. For highly regulated industries, MST offers concrete evidence of software integrity and policy compliance over time. Leadership & Open Standards – We are delivering real transparency now, encouraging a future where all critical software is released with verifiable integrity. MST’s open source implementation and SCITT-compliant design exemplify our commitment to openness and collaboration. We believe widespread adoption of these standards will strengthen supply chain security for everyone, making trust verification a universal practice. Next Steps Microsoft’s Signing Transparency is more than a new security feature and shapes the advances in trust technology. As threats grow more sophisticated, we must evolve the way we assure our customers about the software they depend on. With MST now generally available, we are leading by example: proving that it is possible to open up the traditionally opaque process of software deployment and turn it into a source of strength and trust, i.e., empowering each person with verifiable transparency. We invite the industry to join us on this journey and get started by reading the documentation and exploring Ledger Explorer today! Together, by embracing transparency and open standards, we can turn “trust but verify” from a slogan into an everyday reality for digital infrastructure.
