A stolen password works just as well from an attacker's laptop as from the employee's, unless the web server also checks which device is asking. MITRE D3FEND names this control Endpoint-based Web Server Access Mediation (D3-EBWSAM) and defines it as regulating "web server access directly from user endpoints by implementing mechanisms such as client-side certificates and endpoint security software to authenticate devices and ensure compliant access." It sits under the Isolate tactic as a child of Web Session Access Mediation (D3-WSAM), within Network Resource Access Mediation (D3-NRAM) and Access Mediation (D3-AMED). D3FEND's own example is direct access to internal web applications from company laptops. This card covers what D3-EBWSAM changes, the ATT&CK techniques D3FEND relates to it, how it is built with client certificates and device posture checks, and how to prove an unmanaged device is refused. It is for identity, endpoint and web platform engineers who know the material in the mTLS Guide.
Key takeaways
- The device becomes a second factor for the web server. Access depends on the endpoint proving it is enrolled and healthy, usually with a client certificate whose private key lives on the device.
- Two building blocks, often combined. Mutual TLS at the web server or gateway authenticates the device; an identity provider's device posture policy decides whether that device is compliant right now.
- It blunts credential replay from foreign devices. Passwords and tokens taken from a user are much less useful when the server also requires a device credential the attacker does not hold.
- It does not help once the endpoint itself is compromised. Malware on an enrolled, compliant laptop inherits that device's access, so endpoint detection still matters.
- Verify with a negative test. The proof is an unmanaged device, and a managed device without a certificate, both being refused, with the refusal logged.
D3-EBWSAM at a glance
| Attribute | Value |
|---|---|
| D3FEND ID | D3-EBWSAM (d3f:Endpoint-basedWebServerAccessMediation) |
| Tactic | Isolate |
| Parent technique | Web Session Access Mediation (D3-WSAM), under Network Resource Access Mediation (D3-NRAM) and Access Mediation (D3-AMED) |
| Sibling | Proxy-based Web Server Access Mediation (D3-PBWSAM) |
| Digital artefacts in D3FEND's inferred mapping | Service Application Process and Network Resource (relation: isolates), inherited from the parent techniques |
| D3FEND reference | NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy (final, September 2009) |
| Mechanisms named by D3FEND | Client-side certificates; endpoint security software that authenticates devices |
| Main limitation | Trusts the enrolled device: a compromised compliant endpoint passes the check |
D3FEND's description of this technique is short. Everything beyond the definition on this page is implementation practice from product and standards documentation, not D3FEND guidance.
How it works
The difference from its sibling is where the decision is anchored. Proxy-based mediation puts an intermediary in front of the web server; endpoint-based mediation relies on something only the approved endpoint holds or can attest. Three patterns are common.
- Client certificate at the web server (mutual TLS): the server requests a certificate during the TLS handshake and accepts only those that chain to the organisation's device CA. The certificate is issued at enrolment, ideally with a non-exportable key in a TPM or secure enclave.
- Device posture at the identity provider: the web app trusts single sign-on, and the identity provider's access policy requires the device to be managed and compliant (encrypted, patched, screen lock, endpoint protection running) before it issues the session.
- Endpoint agent attestation: endpoint security software reports device health, and the access decision consumes that signal. Often this is how the identity provider learns compliance.
NIST SP 800-207 states the principle behind all three: no implicit trust is granted to assets or user accounts based solely on their physical or network location, and both user and device are verified before a session with an enterprise resource is established.
ATT&CK techniques D3FEND relates to D3-EBWSAM
Relationship type: inferred only. D3FEND marks these "inferred, experimental" and derives them from the isolates relations to Service Application Process and Network Resource that D3-EBWSAM inherits from its parents (checked November 2026). They are not specific to client certificates, so the third column says where the link is real and where it is only the shared artefact. Each ID was checked against ATT&CK v20.
| ATT&CK ID and technique | Tactic | How D3-EBWSAM applies |
|---|---|---|
| T1213.002 Sharepoint, T1213.001 Confluence | Collection | Real: collaboration sites gated to enrolled devices refuse harvesting from an attacker's own machine with stolen credentials |
| T1003.001 LSASS Memory, T1003.002 Security Account Manager | Credential Access | Partial: dumped passwords alone do not satisfy a device certificate check, but replay from the compromised host itself still works |
| T1074.002 Remote Data Staging | Collection | Partial: internal web upload targets refuse unenrolled devices |
| T1491.002 External Defacement | Impact | Partial: web content management and admin interfaces restricted to enrolled devices are harder to abuse with stolen credentials |
| T1037.003 Network Logon Script, T1505.002 Transport Agent, T1070.005 Network Share Connection Removal | Persistence, Privilege Escalation, Stealth | Shared artefact only: these act on shares, scripts and mail servers rather than web sessions; use the controls on their own technique pages |
D3FEND also lists named techniques without IDs on this card, including Use Alternate Authentication Material, Multi-Factor Authentication Request Generation and Modify Authentication Process. Device-bound access is directly relevant to the first: a stolen session cookie replayed from another device is what device binding is meant to defeat. See the MITRE ATT&CK T1550 Use Alternate Authentication Material Guide and the T1213 Data from Information Repositories Defensive Guide.
Where it is implemented
| Implementation class | Decision point | Device proof | Fits when |
|---|---|---|---|
| Web server mutual TLS | TLS handshake at the server | Client certificate from the device CA | A small number of internal apps you host yourself |
| Load balancer or gateway mutual TLS | TLS termination point in front of the app | Client certificate, with identity passed upstream in a header | Many apps behind shared infrastructure |
| Identity provider device policy | Single sign-on, before the session is issued | Enrolment and compliance state from device management | SaaS and federated apps where you do not control TLS |
| Endpoint security agent signal | Feeds the identity provider or gateway | Agent health and attestation | You need health, not only enrolment, to count |
Web server settings
Servers are listed alphabetically. These are configuration directives from each project's documentation as of November 2026.
- Apache HTTP Server (mod_ssl): SSLVerifyClient takes none (the default), optional, require or optional_no_ca; the documentation says optional_no_ca cannot be relied upon for client authentication. SSLVerifyDepth defaults to 1. SSLCACertificateFile holds the trusted CAs, SSLCARevocationCheck (default none) with chain enables CRL checking, and SSLOCSPEnable turns on OCSP. Set per directory, these force a TLS renegotiation and buffer the request body (SSLRenegBufferSize).
- NGINX (ngx_http_ssl_module): ssl_verify_client takes off (the default), on, optional or optional_no_ca. ssl_client_certificate lists trusted CAs and sends that list to clients; ssl_trusted_certificate does the same without sending it. ssl_crl adds revocation and ssl_verify_depth defaults to 1. The result is in $ssl_client_verify (SUCCESS, FAILED:reason or NONE), and status codes 495 and 496 mark a failed or missing client certificate.
Identity provider device policies
Platforms are listed alphabetically.
- Google Workspace: Context-Aware Access builds access levels from IP, device policy, device OS and geographic origin, and applies them to core services, web apps and SAML apps (SAML apps checked at sign-in). Desktop device policies use Chrome with the Endpoint Verification extension. Availability: Frontline Standard and Plus, Enterprise Standard and Plus, Education Standard and Plus, Enterprise Essentials Plus and Cloud Identity Premium.
- Microsoft Entra ID: a Conditional Access policy with the grant control "Require device to be marked as compliant", backed by an Intune compliance policy. On iOS, Android, macOS and some non-Microsoft browsers the device is identified with a client certificate provisioned at registration. Microsoft documents starting in Report-only mode and excluding emergency access accounts. Availability: Microsoft documents an Intune compliance policy, with at least one compliant device, as a prerequisite.
Policy design in each product is covered in the Conditional Access Guide and the Device Trust and Posture Guide.
Implementation steps
- List the web apps and who should reach them. Mark which are internal only, which are reached from managed devices only, and which need partner or contractor access from devices you do not manage.
- Stand up device identity. Issue device certificates at enrolment from a dedicated CA, with non-exportable keys where the platform supports it, and publish revocation (CRL or OCSP) that servers can reach.
- Define compliance. Decide what "compliant" means (disk encryption, OS patch level, endpoint protection running) and configure it in device management.
- Pilot in observe mode. Use optional client certificate verification and log the result, or a report-only access policy, for two to four weeks. Count which users and devices would have been refused.
- Enforce for one app group. Switch to required verification or an enforced policy for a pilot group, keep break-glass accounts excluded and documented, and give the help desk a script for refused devices.
- Extend and harden. Add revocation checking, short certificate lifetimes with automatic renewal, and offboarding that revokes the device certificate as well as the user account.
- Roll back safely. Revert to optional verification or report-only on the affected app if a certificate or compliance outage blocks users, and record the change.
Where identity fits
Device certificates are non-human identities: they need an owner, an issuance record, a lifetime and revocation on loss or offboarding, just like service account keys. Non-browser clients also call web servers: scripts, agents and integrations. User-scoped device policies do not cover them, and Microsoft notes that service principal calls need workload identity policies instead. Give workloads their own client certificates or workload identity, and see the D3-CBAN Certificate-based Authentication card for certificate authentication itself.
How to verify it works
- Negative tests: from an unmanaged device with valid user credentials, the app must refuse access; repeat from a managed device with its certificate removed and from a device marked non-compliant.
- Revocation test: revoke a test device's certificate and confirm access is refused within the CRL or OCSP refresh window you expect.
- Log review: confirm refusals are logged with device and user detail: for example NGINX 495 and 496 responses with $ssl_client_verify, or the identity provider's sign-in log showing the device compliance result.
- Exception audit: list every bypass (excluded users, apps served without the policy, legacy hostnames) and confirm each has an owner and an expiry.
| Metric | Example target (NHI Mgmt Group suggestion, not a standard) | Why it matters |
|---|---|---|
| Internal web apps enforcing device checks | Rising to all apps in scope | Coverage; one ungated hostname undoes the control |
| Successful sign-ins from unmanaged devices to in-scope apps | Zero, apart from approved exceptions | Direct evidence of enforcement |
| Device certificates revoked within one day of device loss or offboarding | 100% | Stops lost laptops keeping access |
| Active policy exceptions without an expiry | Zero | Exceptions are where bypasses live |
Limits, bypasses and failure patterns
- Compromised compliant endpoints: malware or a hands-on attacker on an enrolled laptop passes every device check. Endpoint detection and session controls remain necessary.
- Exportable keys: a device certificate whose private key can be exported can be copied to another machine, which turns device proof back into a portable secret.
- Revocation not checked: a certificate from a lost laptop keeps working until it expires unless revocation is checked. Turn it on explicitly (SSLCARevocationCheck chain in Apache HTTP Server, ssl_crl in NGINX; neither is set by default).
- Optional modes left on: optional or optional_no_ca verification without an application-level check of the result admits devices without a valid certificate.
- Side doors: the same app reachable on another hostname, a legacy protocol or an API endpoint without the device policy.
- Broad exclusions: service accounts and whole groups excluded during the pilot and never brought back into scope.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-3 Device Identification and Authentication | Authenticating the device before connection is the core of the technique |
| NIST SP 800-53 Rev 5 | AC-3 Access Enforcement, AC-17 Remote Access | Enforcing the access decision for web resources, including remote use |
| NIST CSF 2.0 | PR.AA-03, PR.IR-01 | Users, services and hardware are authenticated; environments protected from unauthorised logical access |
| NIST SP 800-207 | Zero trust tenets | Per-session access decisions that verify both user and device |
| MITRE D3FEND | D3-AMED, D3-NRAM, D3-WSAM, D3-EBWSAM | Hierarchy from access mediation to this technique |
Related countermeasures
- Web Session Access Mediation (D3-WSAM): the parent technique. See D3-WSAM Web Session Access Mediation.
- Proxy-based Web Server Access Mediation (D3-PBWSAM): the sibling that puts the decision in an intermediary. See D3-PBWSAM Proxy-based Web Server Access Mediation.
- Network Resource Access Mediation (D3-NRAM): the wider class. See D3-NRAM Network Resource Access Mediation.
- Access Mediation overview: see the MITRE D3FEND Access Mediation Implementation Guide.
Practitioner checklist
- Inventory internal web apps and decide which must be reachable only from enrolled devices.
- Issue device certificates from a dedicated CA with non-exportable keys where possible.
- Publish CRL or OCSP and turn revocation checking on at every server or gateway.
- Define device compliance in device management and require it in the identity provider policy.
- Pilot in optional or report-only mode, then enforce per app group.
- Keep break-glass accounts excluded, documented and monitored.
- Give workloads their own certificates or workload identity rather than user exclusions.
- Run negative tests from unmanaged and non-compliant devices each quarter.
- Revoke device certificates as part of device loss and offboarding.
Standards and references
- MITRE D3FEND: Endpoint-based Web Server Access Mediation (D3-EBWSAM)
- NIST: SP 800-41 Rev. 1 Guidelines on Firewalls and Firewall Policy
- NIST: SP 800-207 Zero Trust Architecture
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- Apache HTTP Server: mod_ssl
- NGINX: Module ngx_http_ssl_module
- Google Workspace: Protect your business with Context-Aware Access
- Microsoft Learn: Require device compliance with Conditional Access
Related NHI Mgmt Group resources: mTLS Guide · Device Trust and Posture Guide · ZTNA Guide · MITRE D3FEND Guide