Normal TLS validation trusts any certificate that chains to any root in the client's trust store, so one rogue or injected CA is enough to impersonate a server. D3-CP Certificate Pinning is the MITRE D3FEND countermeasure that narrows that trust: D3FEND defines it as "Persisting either a server's X.509 certificate or their public key and comparing that to server's presented identity to allow for greater client confidence in the remote server's identity for SSL connections." It sits in the Harden tactic as a child of Credential Hardening. This card covers what D3-CP hardens, the single ATT&CK technique D3FEND relates it to, where pinning is implemented today, how to verify it and where it breaks. The platform how-to, pin formats and rotation strategy are in the Certificate Pinning guide, which this page links rather than repeats.
Key takeaways
- Pinning hardens the client's view of the server's identity. D3FEND models it as hardening a Certificate and authenticating a Public Key; it does nothing for the server's own private key.
- D3FEND relates it to one ATT&CK technique, by inference. T1649 Steal or Forge Authentication Certificates is linked through the shared Certificate artefact; there is no direct mapping.
- Browsers no longer use it. D3FEND itself notes that pinning in web browsers was deprecated in favour of Certificate Transparency; pinning lives on in native apps, embedded clients and service-to-service code.
- Pin public keys, always with a backup. OWASP, Android and Apple all point to SPKI hashes and more than one pin, so a key change or CA migration does not cut clients off.
- Verification is an interception test. A pinned client must refuse a connection through a proxy whose CA the device trusts; if it connects, the pin is not enforced.
D3-CP at a glance
| Field | D3-CP Certificate Pinning |
|---|---|
| D3FEND ID | D3-CP |
| Tactic | Harden |
| Parent technique | Credential Hardening (siblings: Credential Rotation, Strong Password Policy, Token Binding) |
| Digital artefacts | Certificate (D3FEND: the technique "hardens" a Certificate) and Public Key (the technique "authenticates" a Public Key) |
| Forms D3FEND describes | Certificate pinning (hash of the X.509 certificate), public key pinning, and Subject Public Key Info (SPKI) pinning |
| Typical implementation points | Mobile apps (Android Network Security Configuration, Apple App Transport Security), HTTP client libraries, IoT and embedded firmware, internal service clients |
| Related ATT&CK mitigation | M1054 Software Configuration (D3FEND relates M1054 to D3-CP). See M1054 Software Configuration |
| D3FEND references | OWASP: Certificate and Public Key Pinning; IETF RFC 7469 Public Key Pinning Extension for HTTP; Verizon Digital Media Services patent US9847992B2 End-to-end Certificate Pinning |
| Main limitation | Every pinned key change is a potential outage; an attacker who controls the device can remove pins |
How it works
D3FEND describes two ways to establish a pin: after a trusted first connection (trust on first use) or preloaded in the application, which it calls the preferred method for mobile apps. At connection time the client completes normal chain validation and then compares the presented certificate or key with its stored set. D3FEND's knowledge base distinguishes the forms:
| Form | What is compared | Survives certificate renewal? | Operational note |
|---|---|---|---|
| Certificate pinning | Hash of the whole X.509 certificate | No | D3FEND: pinned certificates must be updated whenever the server updates its certificate |
| Public key pinning | The server's public key | Yes, if the key is reused | D3FEND: keys rotate less often and this form is generally favoured |
| SPKI pinning | Hash of the SubjectPublicKeyInfo, which includes the algorithm | Yes, if the key is reused | The format Android (pin digest SHA-256) and Apple (SPKI-SHA256-BASE64) use |
The level of the chain matters as much as the form. The OWASP Pinning Cheat Sheet does not recommend pinning a root CA, because it trusts every intermediate below it; an intermediate is lower risk but still trusts everything that CA issues; a leaf is recommended only with a backup pin. Apple's guidance leans the other way for operability, suggesting CA public keys where possible so new server certificates from the same CA need no app update. Both agree on pinning more than one key.
Platform mechanisms
- Android: a pin-set inside a domain-config in network_security_config.xml, with pin digest="SHA-256" values of the SPKI. A connection is trusted if at least one public key in the chain matches. The optional expiration attribute (yyyy-MM-dd) turns pinning off after that date; Android's documentation notes this avoids bricking apps that are not updated but may let attackers bypass pins. Apps targeting API 24 and higher trust only system CAs by default, and overridePins on a certificates source defaults to false.
- Apple platforms: NSPinnedDomains under NSAppTransportSecurity in Info.plist, with NSPinnedCAIdentities or NSPinnedLeafIdentities entries of type SPKI-SHA256-BASE64 and an optional NSIncludesSubdomains. Apple states that pinning is not required, should be used only when absolutely necessary, and only tightens default trust evaluation.
- Libraries and services: HTTP clients expose pinning callbacks (OkHttp's CertificatePinner is the example OWASP gives). For internal services, pinning a private CA in the client's trust configuration is usually simpler than pinning leaf keys; see the mTLS Guide.
Why browsers dropped it
RFC 7469 defined an HTTP header that let sites tell browsers to remember their keys. D3FEND notes that browser developers deprecated this approach and now favour certificate analysis through public Certificate Transparency logs. MDN documents that browsers now require certificates to be logged in CT and accompanied by signed certificate timestamps. For web properties, the equivalent control is CT monitoring; see the Certificate Transparency Monitoring Guide for Web Teams and D3-PCA Passive Certificate Analysis.
ATT&CK techniques D3FEND relates to D3-CP
Relationship type: inferred only. D3FEND lists no direct ATT&CK mapping for D3-CP; the single row below is inferred through the shared Certificate artefact and D3FEND labels it experimental (checked November 2026).
| ATT&CK ID | Technique | D3FEND relation (inferred via artefact) | What pinning changes (NHI Mgmt Group assessment) |
|---|---|---|---|
| T1649 | Steal or Forge Authentication Certificates | T1649 forges a Certificate, which D3-CP hardens | Strong against a forged or misissued server certificate with a different key; none if the server's own private key is stolen, because the stolen key is the pinned key |
Two techniques outside D3FEND's D3-CP mapping are where pinning does most of its practical work: T1557 Adversary-in-the-Middle (interception on a hostile network) and T1553.004 Install Root Certificate (an attacker or proxy CA added to the device trust store). The OWASP cheat sheet names exactly these two threats: a rogue certificate from a trusted CA, and a malicious CA injected into the trust store. See the MITRE ATT&CK T1557 Adversary-in-the-Middle and the MITRE ATT&CK T1553 Subvert Trust Controls.
When to use it
| Situation | Pin? | Reason |
|---|---|---|
| Native app or agent where you own the client, the server and the update channel | Consider it | The OWASP cheat sheet's only clear case: pins can be preloaded and updated securely |
| Fleet devices or firmware with reliable forced updates | Consider it, pin a CA key | Leaf rotation without a fast update path causes outages |
| Internal service clients | Prefer a narrow private trust store | Same protection with ordinary rotation |
| Third-party APIs or SaaS endpoints | No | You do not control their key changes |
| Web browsers | Not available | Replaced by Certificate Transparency enforcement |
Implementation steps
- Decide the level and form. Prefer SPKI hashes. Choose leaf with backup, or an issuing CA key, based on how fast you can ship updates.
- Prepare a backup key first. Generate the next key pair (or confirm the second CA) before shipping, and include its pin. Android's documentation states that without a backup you must ship an app update to restore connectivity after a key or CA change.
- Use the platform mechanism, not custom code. OWASP warns that hand-written validation is error-prone; with OpenSSL, for instance, it says to check both the verification result and that a peer certificate exists.
- Decide failure behaviour. No click-through on pin failure; log it on the client and report it. OWASP and Apple both call for a planned fallback and recovery path.
- Tie pins to the certificate lifecycle. Register every pinned key in the certificate inventory so renewal owners know a key change needs an app release. See D3-CERO Certificate Rotation.
- Roll out in stages. Ship to a beta ring, watch pin-failure telemetry, then release widely; keep a configuration update that relaxes the pin set as the rollback.
How to verify it works
- Interception test: route a test device through an intercepting proxy whose CA the device trusts. A pinned client must fail to connect; the OWASP Mobile Application Security Testing Guide covers this test for Android and iOS. See the Mobile App Security Testing Guide.
- Backup pin test: point a staging host at the backup key and confirm clients still connect.
- Release build check: confirm debug-only trust (Android debug-overrides, which skip pinning) is absent from release builds and that no overridePins="true" is set on user CAs.
- Expiry check: list any pin-set expiration dates and confirm they are deliberate.
| Metric (example targets) | What it shows | Target direction |
|---|---|---|
| Pin validation failures per day, by app version and network | Interception attempts or a key change that outran the pin set | Low and explained; spikes investigated |
| Pinned endpoints with at least one backup pin | Outage resilience | 100% |
| Days between a planned key change and the app release carrying the new pin | Whether lifecycle and release are linked | New pin shipped well before the key goes live |
| Share of active installs on a version with the current pin set | How many clients a key change would break | Rising before each rotation |
Limits, bypasses and failure patterns
- Self-inflicted outage: D3FEND warns that servers become unavailable if pinned objects are not updated with rotated identities. Shorter public certificate lifetimes, falling to 47 days by March 2029 under CA/Browser Forum ballot SC081v3, make leaf pinning without key reuse impractical. See the Certificate Expiry Outages and 47-Day TLS Certificates Guide.
- Pinned host key change: when GitHub rotated its exposed RSA SSH host key in March 2023, every client that had stored the old key saw a "remote host identification has changed" warning and some automation failed until updated. SSH known_hosts is a pin in all but name, and the GitHub RSA SSH host key exposure shows why pinned keys need a published fingerprint and a planned replacement path.
- Device-side bypass: anyone controlling the device can repackage or instrument the app to remove pins. Pinning protects users on hostile networks, not your API from its own users; pair it with Mobile App Attestation and server-side controls.
- Stolen server key: pinning cannot detect an attacker who holds the pinned private key. See the Leaked TLS Private Key Response.
- Expiry as a bypass: a pin-set expiration date silently returns clients to ordinary validation.
- Corporate proxies: OWASP advises against allow-listing an inspection proxy unless risk acceptance says to add its key to the pin set; quietly disabling pins for the proxy disables them for attackers too.
Framework mapping
| Framework | Reference | Relationship to D3-CP |
|---|---|---|
| MITRE ATT&CK | M1054 Software Configuration | The mitigation D3FEND relates to D3-CP |
| NIST SP 800-53 Rev 5 | SC-8(1) Cryptographic Protection; SC-23 Session Authenticity | Protecting data in transit and the authenticity of the session endpoint |
| NIST SP 800-53 Rev 5 | IA-9 Service Identification and Authentication | The client authenticating the service it connects to |
| NIST CSF 2.0 | PR.DS-02 | Data in transit protected |
| OWASP | Pinning Cheat Sheet; Mobile Application Security Testing Guide | Implementation guidance and test cases |
Related countermeasures
- Siblings under Credential Hardening: D3-CERO Certificate Rotation (via Credential Rotation) and D3-TB Token Binding.
- Certificate analysis: D3-CA Certificate Analysis and D3-ACA Active Certificate Analysis cover the detection side, including browsers where pinning is gone.
- Client authentication: D3-CBAN Certificate-based Authentication is the mirror control, where the server checks the client.
Practitioner checklist
- Pin only where you control client, server and update channel.
- Pin SPKI hashes, with at least one backup key or CA pin.
- Use Android Network Security Configuration or Apple NSPinnedDomains rather than custom validation code.
- Block click-through on pin failure and send failures to telemetry.
- Register every pinned key in the certificate inventory with a named owner.
- Run an interception test on each release build.
- Review pin-set expiration dates and debug overrides before release.
- Use Certificate Transparency monitoring for web properties instead of pinning.
Standards and references
- MITRE D3FEND: Certificate Pinning (D3-CP)
- OWASP: Pinning Cheat Sheet
- Android Developers: Network security configuration
- Apple Developer: Identity Pinning
- CA/Browser Forum: Ballot SC081v3
- MITRE ATT&CK: T1649 Steal or Forge Authentication Certificates
Related NHI Mgmt Group resources: Certificate Pinning · Mobile App Security Guide · How TLS Works Guide · MITRE D3FEND Guide