A credential that can be presented to any server will eventually be presented to the wrong one, whether that is a phishing proxy, a relay listener or a compromised host the user connected to. MITRE D3FEND names the countermeasure Credential Transmission Scoping (D3-CTS), defines it as "Limiting the transmission of a credential to a scoped set of relying parties", and gives it the synonym Phishing Resistant Authentication. It sits under the Isolate tactic as a child of Access Mediation. This card explains the mechanism behind it, which ATT&CK techniques D3FEND relates to it, the controls that implement it for people (WebAuthn and passkeys), for Windows networks (NTLM restriction and credential delegation policy) and for workloads (audience-restricted tokens), and how to prove the scoping holds. It is for identity architects and Windows and IAM engineers; the rollout side of passkeys is in the Phishing-Resistant MFA Guide.
Key takeaways
- Scoping is a property of the protocol, not of the user. D3-CTS works when the credential or its output is cryptographically tied to the relying party, so a lookalike site or relay cannot reuse it, however convincing the lure.
- WebAuthn is D3FEND's reference. A WebAuthn credential is scoped to a Relying Party ID, the authenticator enforces that scope, and the signed client data carries the origin, so the relying party can reject an assertion made for another origin.
- Manual-entry factors are out of scope. NIST SP 800-63B-4 states that authenticators relying on manual entry of an output, such as OTP and out-of-band codes, shall not be considered phishing resistant, because nothing binds the code to the session.
- The same idea applies beyond browsers. Restricting outgoing NTLM, requiring Remote Credential Guard or Restricted Admin for RDP, and issuing audience-restricted OAuth tokens all limit where a credential can travel or be accepted. These are NHI Mgmt Group's examples, not D3FEND mappings.
- Fallback undoes the control. A scoped credential next to a password, SMS or push fallback leaves the phishable path open; verification means proving the fallback is gone or restricted.
D3-CTS at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-CTS (d3f:CredentialTransmissionScoping) |
| Synonym | Phishing Resistant Authentication |
| Tactic | Isolate |
| Parent technique | Access Mediation (siblings: IO Port Restriction, Network Access Mediation, Network Resource Access Mediation, Operating Mode Restriction, OT Variable Access Restriction, Physical Access Mediation, System Call Filtering) |
| Digital artefact | Credential (D3FEND relation: isolates Credential) |
| D3FEND references | W3C Web Authentication Level 2; NIST SP 800-63C (see-also) |
| What it changes | A credential is accepted only by, or only released to, the relying parties it was scoped to |
| Main limitation | Does not protect a session token after a successful login, or a credential stolen from the endpoint itself |
How it works
NIST SP 800-63B-4 gives the clearest description of the two ways a protocol can scope an authenticator output to the right verifier:
- Verifier name binding: after an authenticated protected channel is set up, the authenticator output is cryptographically bound to a verifier identifier authenticated during the protocol. For DNS names this is the verifier's hostname or a parent domain at least one level below the public suffix. NIST names WebAuthn as an example.
- Channel binding: the authenticator output is bound to an identifier of the specific protected channel, so an impostor cannot relay it over a different channel even with a certificate for the real verifier. NIST considers this the stronger of the two because it does not depend on correctly issued verifier certificates.
In WebAuthn (W3C Web Authentication Level 3, shown as a W3C Recommendation on the W3C site when checked in November 2026), every public key credential is scoped to a Relying Party ID. The RP ID must equal the calling origin's effective domain or be a registrable domain suffix of it, so for an origin of login.example.com the valid RP IDs are login.example.com and example.com. The authenticator only uses a credential in ceremonies requested with the same RP ID, and the browser places the caller's origin in the signed client data. A phishing site on a different domain cannot ask for the real site's credential, and an assertion relayed from it carries the wrong origin. Level 3 also defines related origin requests, which let a relying party list additional origins that may use its RP ID; that list widens the scope and should be treated as part of the control.
NIST SP 800-63B-4 makes phishing resistance required at AAL3 and requires verifiers at AAL2 to offer at least one phishing-resistant option, with federal agencies required to use phishing-resistant authentication for staff, contractors and partners.
Where identity fits
Workloads have the same problem in a different form: a bearer access token accepted by every API in an estate is an unscoped credential. RFC 8707 Resource Indicators for OAuth 2.0 lets a client name the resource it wants, and the authorisation server should restrict the token's audience (the JWT aud claim) to that resource; the RFC's security considerations note that an audience-restricted token received by one resource cannot be replayed at another. Requiring a specific audience at every API, and avoiding tokens with many audiences, is the NHI version of D3-CTS in NHI Mgmt Group's view. Binding a token to a key, as DPoP does, is a different control (it proves possession rather than limiting the audience); see the DPoP Guide.
ATT&CK techniques D3FEND relates to D3-CTS
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CTS. Every row below is inferred because D3-CTS isolates Credential and the technique acts on a Credential or one of its sub-artefacts (D3FEND knowledge graph 1.6.0, labelled "inferred and experimental", checked November 2026). D3FEND lists Keychain under an ID that ATT&CK has revoked; its ATT&CK v20 successor T1555.001 is shown. Unsecured Credentials, Steal Web Session Cookie and Steal Application Access Token appear on the D3FEND page by name; their ATT&CK IDs are added here.
| ATT&CK tactic | Techniques | How much scoping helps |
|---|---|---|
| Credential Access: OS Credential Dumping | T1003.003 NTDS, T1003.005 Cached Domain Credentials, T1003.008 /etc/passwd and /etc/shadow | Little. Dumping happens on a host the attacker already controls; scoping only limits where the dumped material can be used |
| Credential Access: Brute Force | T1110.001 Password Guessing, T1110.002 Password Cracking, T1110.003 Password Spraying | Indirect. Replacing passwords with scoped public key credentials removes the guessable secret |
| Credential Access: Kerberos and web credentials | T1558.001 Golden Ticket, T1606.001 Web Cookies, T1552 Unsecured Credentials, T1539 Steal Web Session Cookie, T1528 Steal Application Access Token, T1555.001 Keychain | Partial. Audience restriction limits where a stolen application token works; session cookies issued after a scoped login remain bearer material |
| Lateral Movement: Use Alternate Authentication Material | T1550.001 Application Access Token, T1550.004 Web Session Cookie | Partial, for audience-restricted tokens |
| Stealth, Privilege Escalation: Access Token Manipulation | T1134.001 Token Impersonation/Theft, T1134.002 Create Process with Token, T1134.003 Make and Impersonate Token | Little; these are local Windows token abuses |
| Persistence, Privilege Escalation: Account Manipulation | T1098.001 Additional Cloud Credentials | Little; added credentials are new, not relayed |
Two techniques that D3FEND does not list are where scoping matters most in practice, in NHI Mgmt Group's view: T1557 Adversary-in-the-Middle, which covers credential relay including NTLM relay and phishing proxies, and T1111 Multi-Factor Authentication Interception. See MITRE ATT&CK T1557 Adversary-in-the-Middle.
Where it is implemented
| Implementation | How it scopes the credential | Key setting or element | Limits |
|---|---|---|---|
| WebAuthn and passkeys (people) | Credential bound to an RP ID; origin signed into client data | RP ID choice; relying party checks of origin and RP ID hash; related origins list | Session cookie after login is still bearer; recovery and fallback paths |
| Certificate-based authentication with TLS client certificates | Proof of the private key is made inside the TLS session with the real server | Mutual TLS at the identity provider or service | Depends on TLS termination design; proxies that terminate TLS break the binding |
| Outgoing NTLM restriction (Windows) | Stops clients sending NTLM responses to servers not on an exception list | "Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers" (Allow all, Audit all, Deny all) with "Add remote server exceptions for NTLM authentication" | Compatibility breaks if the exception list is incomplete |
| RDP credential delegation policy (Windows) | Remote Credential Guard redirects Kerberos requests back to the client, so credentials never reach the target; Restricted Admin does not send them at all | "Restrict delegation of credentials to remote servers" under System, Credentials Delegation (Require Restricted Admin, Require Remote Credential Guard, Restrict credential delegation) | Remote Credential Guard is Kerberos only and direct connections only, not via RD Gateway or Connection Broker |
| Audience-restricted OAuth tokens (workloads) | Token accepted only by the named resource | RFC 8707 resource parameter; aud validation at every API | Multi-audience tokens and APIs that skip aud checks |
For the Windows side, see the NTLM Relay Guide and the NTLM Deprecation and Elimination Guide; WebAuthn internals are in the FIDO2 and WebAuthn Internals Guide.
Implementation steps
- Inventory where credentials travel. List sign-in flows by factor (password, OTP, push, passkey, certificate), Windows hosts still sending NTLM, RDP admin paths and APIs that accept bearer tokens without an audience check.
- Choose RP IDs deliberately. Use the narrowest RP ID that covers the login hosts. A parent domain RP ID lets every subdomain request the credential; keep the related origins list short and owned.
- Enrol scoped credentials for the highest-risk users first. Administrators, help desk and finance first, then everyone. Keep the old factor only during enrolment.
- Remove or restrict fallback. Use conditional access or authentication strength policies so privileged roles cannot complete sign-in with password plus OTP or push. Recovery must not reissue a phishable factor without identity proofing.
- Restrict NTLM in audit mode first. Set "Outgoing NTLM traffic to remote servers" to Audit all, review the NTLM Operational log, add legitimate servers to the exceptions policy, then move to Deny all, as Microsoft advises.
- Enforce RDP delegation policy. Set "Restrict delegation of credentials to remote servers" for administrator workstations. Microsoft recommends Restricted Admin rather than Remote Credential Guard for help desk connections to possibly compromised clients.
- Scope workload tokens. Require the resource parameter or an equivalent audience setting at the authorisation server, and reject tokens with the wrong aud at each API.
- Roll back by group. Each step is policy driven: revert the conditional access policy, move NTLM restriction back to Audit all, or remove the delegation requirement for an affected group while the dependency is fixed.
How to verify it works
- Authorised phishing proxy test: in a red team or purple team exercise, point test users at a lookalike domain fronting the real login. Scoped sign-ins must fail; any success shows a fallback path.
- Sign-in log review: report successful sign-ins for in-scope users by authentication method. Any password-plus-OTP or push success for a privileged user is a gap.
- NTLM audit: the NTLM Operational log on clients should show no outgoing NTLM to servers outside the exception list once Deny all is set.
- RDP check: attempt an administrator RDP connection without /remoteGuard or /RestrictedAdmin from a governed workstation; policy should force the restricted mode.
- Token audience test: present a valid token issued for API A to API B; it must be rejected.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Privileged sign-ins completed with a scoped credential | 100% | Shows fallback is closed where it matters most |
| All-user sign-ins with a scoped credential | Rising each quarter | Adoption across the workforce |
| Hosts sending outgoing NTLM outside exceptions | Zero after enforcement | Relay exposure removed |
| APIs that validate token audience | 100% of internet-facing APIs | Token replay across services prevented |
| Successful logins in phishing proxy exercises | Zero for in-scope users | Direct proof the control holds |
Limits, bypasses and failure patterns
- Phishable fallback left in place: users with a passkey and also SMS or push are only as strong as the weaker factor. The Twilio Breach 2022 began with employees entering credentials on phishing pages, the pattern origin-bound credentials are designed to defeat.
- Push approval treated as phishing resistant: NIST classes out-of-band authentication as not phishing resistant. The Uber Breach 2022 combined a stolen contractor password with repeated push prompts.
- Session theft after a scoped login: the session cookie issued after a WebAuthn sign-in is bearer material. Scoping does nothing against infostealers or token replay; pair it with session controls.
- Over-broad RP ID or related origins: a parent-domain RP ID or a long related origins list widens the set of hosts that can ask for the credential, including forgotten subdomains.
- NTLM exceptions that never shrink: the exception list becomes the new attack surface if it is not reviewed.
- Tokens without audience checks: issuing aud claims is pointless if APIs accept any valid signature.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-63B-4 | Phishing resistance (verifier name binding, channel binding); AAL2 and AAL3 requirements | Defines what counts as scoped, phishing-resistant authentication |
| NIST SP 800-53 Rev 5 | IA-2 Identification and Authentication (Organizational Users), IA-2(8) Access to Accounts, Replay Resistant | Authentication requirements that scoped credentials satisfy |
| NIST SP 800-53 Rev 5 | IA-5 Authenticator Management, AC-4 Information Flow Enforcement | Managing authenticators; restricting where credential flows may go |
| NIST CSF 2.0 | PR.AA-03 | Users, services and hardware are authenticated |
| MITRE ATT&CK mitigations | M1032 Multi-factor Authentication | See M1032 Multi-factor Authentication |
| MITRE D3FEND | Access Mediation, D3-CTS | Parent and technique |
Related countermeasures
- Multi-factor Authentication (D3-MFA): scoping is the property that makes an MFA method phishing resistant. See D3-MFA Multi-factor Authentication.
- Token Binding (D3-TB): ties a token to a key rather than an audience. See D3-TB Token Binding.
- Network Access Mediation (D3-NAM): the network-level sibling under Access Mediation. See D3-NAM Network Access Mediation.
Practitioner checklist
- Pick the narrowest workable WebAuthn RP ID and keep any related origins list owned and short.
- Require scoped credentials for privileged roles with no password, OTP or push fallback.
- Make recovery issue a new scoped credential after identity proofing, not a phishable factor.
- Audit outgoing NTLM, build the exception list, then deny.
- Enforce Restricted Admin or Remote Credential Guard for administrator RDP.
- Issue audience-restricted tokens and validate aud at every API.
- Run phishing proxy tests in authorised exercises and track successful logins.
- Pair scoping with session token protections, since it ends at login.
Standards and references
- MITRE D3FEND: Credential Transmission Scoping (D3-CTS)
- W3C: Web Authentication Level 3
- W3C: Web Authentication Level 2
- NIST: SP 800-63B-4 Authentication and Authenticator Management
- IETF: RFC 8707 Resource Indicators for OAuth 2.0
- Microsoft Learn: Restrict NTLM, outgoing NTLM traffic to remote servers
- Microsoft Learn: Remote Credential Guard
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: D3-CBAN Certificate-based Authentication · Phishing-Resistant MFA Guide · FIDO2 and WebAuthn Internals Guide · NTLM Relay Guide · MITRE D3FEND Access Mediation Implementation Guide · MITRE D3FEND Guide