diff --git a/articles/connect-end-user-to-wifi-with-certificate.md b/articles/connect-end-user-to-wifi-with-certificate.md
index df795914413..cffa58ccd0d 100644
--- a/articles/connect-end-user-to-wifi-with-certificate.md
+++ b/articles/connect-end-user-to-wifi-with-certificate.md
@@ -764,7 +764,7 @@ Automatic renewal is only supported if the validity period is set to 2 days or l
 
 If an end user is on vacation (offline for more than 30 days), their certificate might expire, and they'll lose access to Wi-Fi or VPN. To reconnect them, ask your end users to temporarily connect to a different network so that Fleet can deliver a new certificate.
 
-Fleet automatically retries each failed macOS, iOS, and iPadOS certificate up to 3 times per host and each failed Windows certificate once per host, checking every 30 seconds for certificates to resend. Learn more in the [4.38.0 release article](https://fleetdm.com/releases/fleet-4-38-0#failed-profile-redelivery). Automatic retries for Android is coming soon. Note that manually resending a profile does not reset the automatic retry counter.
+Fleet automatically retries each failed macOS, iOS, iPadOS, and Android certificate up to 3 times per host and each failed Windows certificate once per host, checking every 30 seconds for certificates to resend. Learn more in the [4.38.0 release article](https://fleetdm.com/releases/fleet-4-38-0#failed-profile-redelivery). Note that manually resending a profile does not reset the automatic retry counter.
 
 > Currently, for NDES, Smallstep, and custom SCEP CAs, Fleet requires that the ⁠`$FLEET_VAR_SCEP_RENEWAL_ID` variable is in the certificate's OU (Organizational Unit) for automatic renewal to work for Apple and Windows hosts. For some CAs, including [NDES](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/active-directory-domain-services-maximum-limits?utm_source=chatgpt.com#:~:text=OU%20names%20can%20only%20be%2064%20characters%20long.), the OU has a maximum length of 64 characters so any characters beyond this limit get truncated, causing the renewal to fail.
 >
diff --git a/docs/Contributing/product-groups/security-compliance/android-certificates.md b/docs/Contributing/product-groups/security-compliance/android-certificates.md
index 53f81b90aad..9e81a94e120 100644
--- a/docs/Contributing/product-groups/security-compliance/android-certificates.md
+++ b/docs/Contributing/product-groups/security-compliance/android-certificates.md
@@ -70,3 +70,33 @@ flowchart TD
     certInstallStatus --> status["Update status on host details"]
     status --> done(["Done"])
 ```
+
+## Retry behavior
+
+Certificate installs have two layers of retry:
+
+### Client-side retry (Android agent)
+
+When SCEP enrollment fails on the device, the Android agent retries up to 3 times locally before
+reporting the failure to the Fleet server via `PUT /api/fleetd/certificates/:id/status`.
+
+### Server-side retry (Fleet server)
+
+When the agent reports a certificate install failure, the Fleet server automatically retries up to
+3 times by resetting the certificate status to `pending` so it gets re-delivered on the next cron
+cycle. Each failure is logged as an `installed_certificate` activity with `status: "failed_install"`
+so IT admins have visibility into retry attempts.
+
+After all server-side retries are exhausted (`retry_count = MaxCertificateInstallRetries = 3`), the
+certificate is marked as terminally `failed`.
+
+### Manual resend
+
+When an IT admin clicks "Resend" in the Fleet UI, the certificate is reset to `pending` with
+`retry_count` set to `MaxCertificateInstallRetries`. This means the resend gets exactly one delivery
+attempt with no automatic server-side retry on failure, matching Apple resend behavior.
+
+### Certificate renewal
+
+When a certificate approaches expiration and is automatically renewed, `retry_count` is reset to 0,
+giving it a fresh retry budget.