Protected Users, Credential Guard, and MFA: Protection Scope and Boundaries.

1. Core mechanism

Treating credential protection as one master switch is the most common design mistake. The right question is not “Are we protected?” but “Which control is active on which machine, at which protocol step, and for which secret?” The Protected Users group changes behavior both on the client where the member signs in and on the domain controller, and part of its effect depends on the domain functional level. Credential Guard is a local platform control: it isolates LSA secrets, but does not protect the directory itself or a session the user already has open. MFA is evaluated in a cloud or federated sign-in flow; it does not enter an on-premises Kerberos or NTLM handshake. All three controls are real and valuable, but their scopes are not interchangeable.

Interfaces and specifications

• Protected Users: A global security group defined in Active Directory. Membership imposes client-side restrictions on the Windows device where the member signs in; when the domain functional level is Windows Server 2012 R2 or later, it also imposes additional restrictions on the domain controller.
• Protected Users client side: on supported Windows, NTOWF, long-term Kerberos keys and offline logon verifier are not cached; CredSSP/WDigest plaintext credential caching is prevented. DC-side protocol restrictions have a separate DFL prerequisite.
• Protected Users, domain side: members cannot authenticate with NTLM, cannot use DES or RC4 for Kerberos pre-authentication, cannot be delegated through delegation (constrained or unconstrained), and their initial TGT lifetime is shortened in a way that cannot be renewed.
• Credential Guard: A Windows platform control. It uses virtualization-based security to keep LSA secrets in an isolated process; its goal is to prevent the NTLM password hash, Kerberos TGT, and domain credentials from being extracted from the operating system.
• What Credential Guard does not cover: the Active Directory database itself, local and Microsoft accounts, third-party authentication packages, or attack classes such as physical access and keylogging.
• MFA: A control that requests a second verification factor during sign-in on the Microsoft Entra ID side. It affects the token issuance decision; it does not inject an additional factor into an in-domain Kerberos ticket exchange or an NTLM session.

Three controls, three separate boundaries

Protected Users is a group membership, but its effect is unlike ordinary group membership. A normal group grants access to a resource; Protected Users instead narrows the authentication paths available to the account. Part of this narrowing is applied on the member’s device and part on the domain controller. Therefore, “we added the user to the group” does not by itself describe the full protection: the client operating-system version and domain functional level determine which restrictions are actually active.

Credential Guard’s boundary is the machine. The protection is isolation of that device’s LSA secrets. This makes it harder for an attacker with administrator rights to extract a hash or ticket from memory. But preventing an attacker who already has an authorized session on the device from using that session’s privileges is not Credential Guard’s job. The protection focuses on taking the secret out, not using the secret in place.

MFA’s boundary is the protocol. Requesting an additional factor in the Entra ID sign-in flow does not mean that the same user will see an additional factor while connecting to an on-premises file server over SMB; Entra ID is not the component making the decision on that path. MFA is therefore a strong control for cloud application access, not a direct control for lateral movement inside the network.

Write the scope map on three axes

The practical way to understand what these three controls do in an environment is to describe each one on three axes: where it is applied, which secret or decision it covers, and which unmet condition can silently make it ineffective. For Protected Users, the third axis is the domain functional level and client version. For Credential Guard, it is the hardware and virtualization-based security requirements. For MFA, it is whether the access path actually passes through Entra ID.

Once this table is filled in, it becomes clear that the three controls reduce the same risk from different sides, but none replaces another. Protected Users prevents an account from authenticating with weak protocols; Credential Guard makes it harder to steal that account’s credentials from a device; MFA ensures that a stolen password alone is insufficient for cloud access.

Protection creates compatibility costs

Protected Users membership stops an application that depends on NTLM or RC4 from working with that account. This is not a bug; it is the definition of the control. Microsoft therefore recommends rolling out the group incrementally and with testing, and not adding service or computer accounts: membership can cause unexpected outages for these accounts.

Credential Guard likewise does not work with some older authentication paths; Microsoft lists them separately in a compatibility list. Both controls therefore require the old protocol dependencies in the inventory to be found before the security gain can be realized. Instead of enabling a control and waiting for an outage, identify in advance which account depends on which protocol.

State and data flow

1. Compare membership and a supported client: no NTOWF/long-term-key/offline-verifier cache or CredSSP/WDigest plaintext cache. This is separate from DFL-dependent DC restrictions.
2. If the domain functional level is Windows Server 2012 R2 or later, the domain-controller side also takes effect: the member cannot authenticate with NTLM, cannot be delegated, and its initial TGT has a short lifetime that cannot be renewed.
3. When the same account signs in on a device with Credential Guard enabled, the resulting Kerberos and NTLM secrets are held in an isolated LSA process; extraction from the operating system is blocked as far as the control is designed to do so.
4. When the user accesses a cloud application, MFA is evaluated in the Entra ID sign-in flow. The same user’s in-domain Kerberos ticket request does not pass through that flow and no additional factor is requested.
5. Read 4768 fields separately: TicketEncryptionType is TGT encryption; PreAuthType is a method. This Version0 excerpt has no PreAuthEncryptionType or membership proof. Verify client, DFL, membership and protocol restrictions separately.

2. Exploitation

Broken trust assumption

The assumption that “we added the account to Protected Users, Credential Guard is enabled, and MFA is required; credential theft is now solved for us.” The conclusion is that the three controls complement one another and close every path, making it a secondary detail which device privileged accounts are used on, which protocols remain enabled, and which sessions are still alive.

Technical prerequisites

• Protected Users membership exists for the privileged target account, but the domain functional level and client operating-system version have not been verified; it is unknown which restrictions actually apply.
• Credential Guard is reported as “enabled,” but it is not monitored which devices actually run it or whether privileged accounts are used only on those devices.
• The MFA policy is defined for cloud sign-in; paths by which the same account accesses on-premises resources are assumed to be covered by the same policy.
• The servers where privileged accounts sign in interactively and how long those sessions remain alive are not reviewed regularly.

Exploitation mechanism

The mechanism behind the false confidence is scope drift. Protected Users’ domain-side restrictions depend on the domain functional level; if the condition is not met, the group exists but some expected restrictions do not. Credential Guard is designed to focus on the “secret extraction” class; Microsoft documentation explicitly says that this protection does not cover the Active Directory database, local accounts, or attack classes such as physical access and keylogging. Thus, even if a credential cannot be extracted from memory, the privilege of an already-open privileged session on the same device can still be used. MFA’s scope drift is the clearest: the additional factor is requested in the token issuer’s sign-in decision. A cloud access attempt may be blocked when an account’s password is stolen, but resources reachable over Kerberos on the internal network with the same credentials do not pass through that decision. The combined effect of the three controls approaches the expected level only when the privileged-account usage surface is genuinely narrowed—not simply because the controls were enabled.

Conditional protection is not protection when the condition is unverified

The most important property of Protected Users is that its effect is split across two sides. Client-side restrictions are applied on the device where the member signs in, on supported Windows versions. Domain-side restrictions are applied when the domain functional level is Windows Server 2012 R2 or later. This distinction is documented and is the first thing that should be verified in an assessment.

The common practical picture is this: the group has been created and privileged accounts have been added, but the environment still uses an older functional level or some administrative workstations run an older client version. The result is a control that appears green in an assessment report but is actually partial. This lesson does not describe an exploitation method; it explains that the written conditions defining control scope must be verified separately in every assessment.

The secret is protected; the session is not

Credential Guard is intended to prevent credentials from being extracted from a device. This makes many lateral-movement techniques that depend on credential theft more expensive. Microsoft’s own documentation, however, clearly lists the protection’s limits: the Active Directory database, local and Microsoft accounts, third-party authentication packages, and physical access or keylogging are outside its scope.

The defensive lesson is clear: the security of a privileged account cannot be considered independently of the devices on which that account is used. Tiering, privileged access workstations, and session-duration limits do not replace the platform control; they are what make it meaningful.

An additional factor does not cross a protocol boundary

MFA is evaluated in the token issuer’s sign-in flow. Therefore, the statement “MFA is required” should always be written together with a scope statement: which applications, which sign-in path, and under which conditions. Without that scope statement, the phrase is read as if it covered the entire environment.

This scope drift is especially dangerous in hybrid environments because the same username appears on two different access paths. The cloud side may request an additional factor, while the same identity’s on-premises Kerberos path is outside that decision. Keep the two paths on separate lines in the risk analysis and record which control is active for each line.

3. Defense & Detection

Telemetry scope

• Record Protected Users membership together with three facts: the member list, the domain functional level, and the operating-system versions of the clients where members sign in. Without all three, the control’s scope is ambiguous.
• Verify that service and computer accounts are not in Protected Users; membership is likely to cause unexpected outages for these accounts and is not recommended.
• Keep Credential Guard status as a field in the device inventory and monitor separately whether privileged accounts are used only on those devices.
• List the MFA policy’s scope at the application and sign-in-path level; explicitly document access paths outside that scope in the same record.
• Sample Kerberos pre-authentication encryption types from DC events; RC4 is not expected for Protected Users members, while AES is expected.
• Monitor group-membership changes through directory auditing: removing an account from Protected Users means that protection has been silently removed.

Events and relevant fields

• The mere existence of Protected Users membership is not evidence of protection; if the domain functional level condition is not met, domain-side restrictions are not applied.
• A Kerberos ticket obtained with AES does not by itself prove Protected Users membership; AES may also be the default for accounts that are not members.
• An event observed on a device with Credential Guard enabled does not prove that credentials were not stolen; attack classes outside the protection are documented.
• A cloud sign-in completed with MFA does not show that the same user’s access to on-premises resources is protected by an additional factor.
• A rejected NTLM path usually appears to the application as a generic authentication error; investigate the root cause within the control’s scope.

Keep the control record with its conditions

The field that produces the most errors in assessment documents is the control’s binary status. A row saying “Protected Users applied” does not say which restrictions are actually active. It becomes auditable when the same row says “domain functional level 2012 R2, clients on supported versions, members are human privileged accounts only.”

The same approach applies to the other two controls. The Credential Guard row should state which device group is enabled, and the MFA row should state which access paths it covers. Without those details, an incident review cannot answer why the control failed to show its expected effect.

Collect telemetry where the control is applied

The domain-side effect of Protected Users appears on the domain controller, while the client-side effect appears on the device where the member signs in. Looking in one source alone is therefore misleading. Kerberos authentication service events are searched for on the DC; records about session creation are searched for on the machine where the session was opened.

This distinction is fundamental to building the evidence chain correctly during incident review. When someone claims that a control failed to show its expected effect, first ask whether the correct source was checked. If the relevant audit subcategory is not enabled, the absence of an event does not mean the absence of behavior.

Detection logic · XPath

<QueryList><Query Id="0" Path="Security"><Select Path="Security">*[System[EventID=4768] and EventData[Data[@Name='TargetUserName']='arin.demir']]</Select></Query></QueryList>

Query assumptions

• This XPath is only a format example and has not been run on any Windows system in this session; the EventID and TargetUserName predicates are in one event-node selector. Field names can vary by event version.
• The query targets the domain controller’s Security channel; Kerberos authentication service events are recorded on the DC, not on the client.
• The relevant audit subcategory must be enabled for events to appear; a query returning no results does not mean that authentication did not occur.
• Interpret TicketEncryptionType according to the documentation; this query does not classify the encryption type by itself.
• arin.demir is a fictional human-user account name, not evidence of group membership. In this Version 0 excerpt, TicketEncryptionType describes TGT encryption; PreAuthType=2 describes the pre-authentication method, not its encryption type. The updated Version 2 event has a separate PreAuthEncryptionType field; do not infer it from the two older fields.

False positives

• If the same account name is used in different contexts, the returned events may not belong to one user activity.
• Renewal and service-ticket requests also appear with the same account name; one event row does not mean a session started.
• Negative example: an account that is not a Protected Users member may also perform AES pre-authentication; the encryption type alone is not evidence of membership.
• In an environment with multiple DCs, the query sees only the record on the DC where it is run; an incomplete result does not mean the event never occurred.

Hardening

• Roll out Protected Users first to a small, well-understood set of privileged human accounts; record which application depends on which protocol in each wave.
• Write the domain functional level condition into the control record; if the condition is not met, mark the control as partial.
• Keep service and computer accounts outside Protected Users; use separate hardening paths for these accounts.
• Restrict privileged-account use to Credential Guard-enabled, managed, and few devices; keep the device list traceable in the inventory.
• Write the MFA scope document by access path; define a separate compensating control for on-premises paths outside the scope.
• Do not reduce the state of the three controls to one “protected” flag; keep separate scope, condition, and evidence rows for each control.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing"/><EventID>4768</EventID><Version>0</Version><Level>0</Level><Task>14339</Task><TimeCreated SystemTime="2026-10-01T07:41:52.0000000Z"/><EventRecordID>1405001</EventRecordID><Channel>Security</Channel><Computer>dc02.outreason.example</Computer><Security/></System><EventData><Data Name="TargetUserName">arin.demir</Data><Data Name="TargetDomainName">OUTREASON.EXAMPLE</Data><Data Name="ServiceName">krbtgt</Data><Data Name="TicketEncryptionType">0x12</Data><Data Name="PreAuthType">2</Data><Data Name="Status">0x0</Data><Data Name="IpAddress">::ffff:198.51.100.37</Data><Data Name="IpPort">51344</Data></EventData></Event>

Two reality checks

Assumption: Adding accounts to the Protected Users group means that those accounts are protected against credential theft.

In fact: Membership is conditional: a supported client restricts NTOWF/long-term-key/offline-verifier caching and CredSSP/WDigest plaintext caching. DC-side NTLM/DES-RC4 pre-auth/delegation/TGT restrictions require Windows Server2012R2+ DFL. Verify membership, client and DFL separately; service/computer accounts are not recommended members.

Assumption: If Credential Guard is enabled, credentials cannot be stolen; if MFA is required, a stolen password is useless anyway.

In fact: Both statements are conditional. Credential Guard uses virtualization-based security to isolate LSA secrets and aims to prevent credentials from being extracted from the operating system; Microsoft states that this protection does not cover the Active Directory database, local and Microsoft accounts, third-party authentication packages, or attack classes such as physical access and keylogging. MFA is evaluated in the Entra ID sign-in flow; resources accessed with on-premises Kerberos or NTLM do not pass through that decision. Both controls therefore provide real benefits, but neither replaces reducing the privileged-access surface.

Sources

• Microsoft · Protected Users Security Group
  Protected Users client-side restrictions (NTLM, the CredSSP/WDigest plaintext cache, DES/RC4 pre-authentication, and offline sign-in) and domain-side restrictions effective at the Windows Server 2012 R2 domain functional level and later (NTLM rejection, delegation prohibition, and a shortened non-renewable TGT); warning for service and computer accounts.
• Microsoft · Credential Guard overview
  Isolation of LSA secrets with virtualization-based security and the credential types protected.
• Microsoft · Credential Guard protection limits
  Areas not protected by Credential Guard: the Active Directory database, local and Microsoft accounts, third-party authentication packages, and attack classes such as physical access and keylogging.
• Microsoft · How Microsoft Entra multifactor authentication works
  The additional verification factor requested in the Entra ID sign-in flow and MFA’s evaluation as part of the sign-in decision.
• Microsoft · 4768(S, F) A Kerberos authentication ticket (TGT) was requested
  EventData fields: TargetUserName, ServiceName, TicketEncryptionType, PreAuthType, Status, IpAddress; the event is recorded on the domain controller.
• Microsoft · Consuming Events (Windows Event Log)
  Windows Event Log XPath subset; event-node selector in one Select expression and combined predicates over fields from the same event.