Certificate pinning on Android POS

Certificate pinning on Android is a well-documented technique. The technique itself is fine; the operational reality of running it across a diverse Android POS fleet is where the trouble lives.

Written September 2025 from a fleet integration review.

The pinning options

• Leaf certificate pin. Highest security, most fragile. Any certificate rotation breaks every device.
• Intermediate certificate pin. Better balance. Rotations of the leaf are safe; rotations of the intermediate require coordinated device updates.
• Public key pin. Rotations of the certificate itself are safe as long as the public key doesn't change. Key rotations still require coordination.
• Certificate transparency pin. Trust the CT logs; verify via them. Rarely used on mobile.

What actually happens in a fleet

A few patterns from the field:

• Devices with stale time. A device with a clock that's drifted more than a few days will reject any certificate as expired or not-yet-valid. Time sync is more important than the pinning strategy.
• Legacy Android versions. Devices running Android 7 or earlier don't handle certificate chains the same way as current versions. Pin behavior varies by SDK version.
• The rotation window that isn't rehearsed. The pin is due to expire; the vendor has issued a new intermediate; the fleet update lags. Suddenly a fraction of the fleet is offline for authorization.

What to build

• Backup pins. Pin the current and the next-in-rotation intermediate. This buys you time for the fleet update.
• A well-monitored update pipeline. You need to know within hours, not weeks, if a segment of the fleet failed to accept the new pin.
• A soft-failure mode for edge cases. Terminals that can't validate the pin should surface it clearly to the operator, not silently accept a downgraded connection.

Pinning is good. Pinning without a rotation plan is a scheduled outage.