What is certificate pinning? A Practitioner's Definition

Definition

Certificate pinning is a TLS validation technique that makes an application trust only a specified certificate, public key, or certificate authority for a service. It adds a narrower trust rule on top of normal certificate validation, reducing the chance that a compromised or misissued certificate will be accepted.

Analyst’s Take: Pinning is a narrower acceptance rule, not a replacement for TLS validation. Its value depends on whether the team can rotate pins and recover from mistakes without cutting off every pinned client.

How certificate pinning works

Normally, a TLS client validates a server certificate by checking several properties:

1. The certificate is within its validity period.
2. The hostname matches the certificate’s subject or subject alternative name.
3. The certificate chains to a trusted root or intermediate authority.
4. The certificate has not failed applicable policy checks, such as key-usage validation.

Without pinning, any certificate issued by a trusted certificate authority may be accepted if it passes those checks. Certificate pinning adds an additional condition: the presented certificate or its public key must match a value the application already expects.

There are several common pinning models:

• Certificate pinning: The application stores a specific server certificate and compares the presented certificate against it.
• Public key pinning: The application stores a hash or representation of the expected public key. A renewed certificate can remain trusted if it uses the same key.
• CA or intermediate pinning: The application accepts certificates only when they chain through a specified authority or intermediate certificate.
• Backup pinning: The application stores more than one valid key or certificate, allowing planned rotation if one value is currently active and another is reserved.

A typical implementation performs ordinary TLS validation first, then applies the pinning check. A valid certificate from an unexpected authority should still fail the application’s pinning policy.

Pinning does not encrypt traffic beyond what TLS already provides. It also does not automatically stop every man-in-the-middle attack. Its value is reducing the set of certificates or keys that the client will accept, particularly when an attacker has obtained a fraudulent certificate trusted by the device or operating system.

Technical notes: simplified validation logic

The following pseudocode illustrates the concept. Real implementations should use platform-supported APIs and carefully handle key encoding, certificate chains, and rotation:

connect to api.example.com using TLS

if normal_certificate_validation_fails:
    reject connection

presented_public_key = extract_server_public_key()
expected_keys = [active_key, backup_key]

if hash(presented_public_key) is not in expected_keys:
    reject connection

allow application traffic

Do not treat a hostname check, a certificate expiration check, or a custom “accept any certificate” callback as certificate pinning. Disabling normal validation creates a serious trust failure. Pinning should narrow validation, not replace it.

Where you’ll encounter certificate pinning

Mobile applications

Certificate pinning is common in mobile applications that communicate with sensitive APIs. Developers may use it to reduce exposure to hostile Wi-Fi networks, local malware, compromised device trust stores, or misissued certificates.

Mobile platforms generally provide mechanisms for custom trust decisions or declarative network security policy. For example, an Android application may define certificate trust anchors in a Network Security Configuration file:

<network-security-config>
    <domain-config>
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">BASE64_ENCODED_SPKI_HASH</pin>
            <pin digest="SHA-256">BASE64_ENCODED_BACKUP_SPKI_HASH</pin>
        </pin-set>
    </domain-config>
</network-security-config>

The exact configuration and platform behavior depend on the operating system version and application architecture. Test pinning on supported devices, including upgrade and recovery paths.

API clients and embedded software

Pinning may appear in desktop agents, payment clients, SDKs, IoT devices, and other software that communicates with a small, known set of endpoints. It is more defensible when the organization controls both the client and the server and can distribute updates or configuration changes reliably.

It is less suitable for general-purpose software that connects to arbitrary customer-controlled domains. In those cases, a fixed pin can break legitimate deployments, TLS inspection, private certificate authorities, and managed enterprise proxies.

Corporate TLS inspection

Security gateways often intercept TLS connections and re-encrypt traffic with certificates issued by an enterprise CA. A pinned application may reject those connections even when the enterprise has installed its CA correctly.

This can be intentional: pinning prevents the application from accepting an intermediary certificate generated by a local inspection device. It can also create support problems. Security teams should document which applications use pinning before deploying inspection policies or troubleshooting connection failures.

Legacy browser deployments

HTTP Public Key Pinning, or HPKP, allowed websites to advertise pins to browsers through an HTTP response header. Operational mistakes could make a site unreachable for users until the pin policy expired, while attackers could potentially abuse pinning headers in some scenarios.

HPKP has been removed from modern browser practice and should not be introduced for new web properties. Web administrators should use standard certificate lifecycle controls, secure TLS configuration, certificate transparency monitoring where appropriate, and reliable certificate authority processes instead.

Is certificate pinning still recommended?

There is no universal yes-or-no answer.

Do not use legacy HPKP for websites. It created significant availability and recovery risks and is not a modern browser security recommendation.

Consider application-level pinning selectively. It may provide meaningful defense-in-depth for a high-value mobile app or tightly controlled client, especially when the threat model includes fraudulent publicly trusted certificates. The decision should account for:

• The sensitivity of the data and actions exposed by the application.
• Whether the client and server are both under organizational control.
• How quickly clients can receive updates or configuration changes.
• Whether backup pins and an emergency recovery mechanism exist.
• The impact on enterprise proxies, debugging, incident response, and disaster recovery.
• The organization’s ability to test certificate and key rotation before production.

Pinning also introduces a self-inflicted denial-of-service risk. An expired certificate, changed key, lost backup key, or incorrectly deployed pin can prevent every pinned client from connecting. Maintain at least one tested backup value and treat pin changes as a production change requiring staged rollout.

For many organizations, strong certificate lifecycle management, private key protection, short detection and response times, secure platform defaults, and application-layer authentication provide more dependable risk reduction than pinning alone. For example, teams should understand how application credentials such as a bearer token are protected independently of transport-layer controls.

Start by deciding whether the client and server are sufficiently controlled to support tested rotation and recovery. If they are not, pinning is more likely to create an outage than reduce risk.

Practical implementation checklist

Before enabling application-level certificate pinning, confirm that your team can:

1. Identify the exact certificate, public key, or CA value being pinned.
2. Perform normal hostname and certificate-chain validation first.
3. Maintain at least one tested backup pin.
4. Rotate certificates and keys in a staging environment.
5. Release updated pins before retiring the currently trusted value.
6. Provide an emergency recovery path for clients that cannot connect.
7. Document how pinning interacts with enterprise TLS inspection.
8. Monitor connection failures after every pin or certificate change.
9. Test upgrades, rollbacks, offline devices, and abandoned client versions.
10. Define whether pinning remains necessary as the threat model changes.

If a suspected endpoint compromise also requires host investigation, follow a documented evidence-preservation process rather than treating pinning as a forensic control. A practical starting point is this Windows digital forensics guide.

For basic malware screening on a potentially affected workstation, a reputable endpoint protection tool such as Get Malwarebytes → may be useful. It does not replace enterprise detection, incident response, or forensic collection.

Related terms

• TLS: The protocol that protects data in transit and authenticates endpoints using certificates.
• Certificate authority (CA): An entity trusted to issue certificates for identities such as domain names.
• Public key pinning: A pinning method that matches an expected public key or its hash instead of an entire certificate.
• HPKP: A deprecated browser mechanism for advertising public key pins through HTTP headers.
• mTLS: Mutual TLS, where both client and server authenticate with certificates. It is different from pinning, although the controls can be used together.
• Trust store: A collection of trusted root certificates maintained by an operating system, browser, or application.
• Certificate transparency: A system for publicly recording many newly issued TLS certificates so misissuance can be detected.
• TLS inspection: Interception and re-encryption of TLS traffic by a security gateway or proxy, often incompatible with certificate pinning.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.