diff --git a/assets/images/real-device-app-testing/Certificate-Injection/certificates-launch-page.webp b/assets/images/real-device-app-testing/Certificate-Injection/certificates-launch-page.webp
new file mode 100644
index 000000000..80e0a613d
Binary files /dev/null and b/assets/images/real-device-app-testing/Certificate-Injection/certificates-launch-page.webp differ
diff --git a/assets/images/real-device-app-testing/Certificate-Injection/session-android-settings-certificates.webp b/assets/images/real-device-app-testing/Certificate-Injection/session-android-settings-certificates.webp
new file mode 100644
index 000000000..3dd92a6f1
Binary files /dev/null and b/assets/images/real-device-app-testing/Certificate-Injection/session-android-settings-certificates.webp differ
diff --git a/assets/images/real-device-app-testing/Certificate-Injection/session-certificates-panel.webp b/assets/images/real-device-app-testing/Certificate-Injection/session-certificates-panel.webp
new file mode 100644
index 000000000..4f95c9402
Binary files /dev/null and b/assets/images/real-device-app-testing/Certificate-Injection/session-certificates-panel.webp differ
diff --git a/docs/certificate-injection-appautomation.md b/docs/certificate-injection-appautomation.md
new file mode 100644
index 000000000..24c4a915f
--- /dev/null
+++ b/docs/certificate-injection-appautomation.md
@@ -0,0 +1,407 @@
+---
+id: certificate-injection-appautomation
+title: Certificate Injection in App Automation on Real Devices
+sidebar_label: Certificate Injection
+description: Install custom CA certificates and client identities on TestMu AI real devices during Appium app automation sessions to test certificate-based authentication, SSL pinning, and mutual TLS.
+keywords:
+  - certificate injection
+  - certificate based authentication
+  - custom certificates
+  - customCertificates capability
+  - ssl pinning
+  - mutual tls
+  - client certificate
+  - ca certificate
+  - pkcs12 pfx
+  - mobileconfig
+  - appium automation
+  - app test automation
+  - testmu ai
+  - real devices
+url: https://www.testmuai.com/support/docs/certificate-injection-appautomation/
+site_name: TestMu AI
+slug: certificate-injection-appautomation/
+canonical: https://www.testmuai.com/support/docs/certificate-injection-appautomation/
+---
+
+import CodeBlock from '@theme/CodeBlock';
+import { YOUR_LAMBDATEST_USERNAME, YOUR_LAMBDATEST_ACCESS_KEY } from "@site/src/component/keys";
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import RealDeviceTag from '../src/component/realDevice';
+import BrandName, { BRAND_URL } from '@site/src/component/BrandName';
+
+
+<script type="application/ld+json"
+      dangerouslySetInnerHTML={{ __html: JSON.stringify({
+       "@context": "https://schema.org",
+        "@type": "BreadcrumbList",
+        "itemListElement": [{
+          "@type": "ListItem",
+          "position": 1,
+          "name": "Home",
+          "item": BRAND_URL
+        },{
+          "@type": "ListItem",
+          "position": 2,
+          "name": "Support",
+          "item": `${BRAND_URL}/support/docs/`
+        },{
+          "@type": "ListItem",
+          "position": 3,
+          "name": "Certificate Injection in App Automation",
+          "item": `${BRAND_URL}/support/docs/certificate-injection-appautomation/`
+        }]
+      })
+    }}
+></script>
+
+<RealDeviceTag value="Real Device" />
+
+Many apps connect to servers that use certificates issued by a private or corporate certificate authority. Some apps also pin a **self-signed certificate**, or present a **client certificate** to authenticate themselves before a server will respond. On a standard device, these connections fail because the device does not trust your organization's certificates.
+
+<BrandName />'s **Certificate Injection** allows you to test certificate-based authentication on real devices. You upload a certificate once and reference it by ID in your Appium capabilities. <BrandName /> then installs it on the allocated device before your test begins, with no manual steps on the device and no password entry during the run. Certificates are removed when the session ends.
+
+---
+
+## Use Cases
+
+- Automate **certificate-based authentication** flows without manually entering a password on the device.
+- Run regression suites against **internal or staging endpoints** signed by a private certificate authority.
+- Validate **mutual TLS (mTLS)** handshakes where your app must present a client certificate.
+- Test builds with **SSL pinning** enabled against a self-signed certificate.
+
+---
+
+## Supported Formats and Constraints
+
+The file extension determines how a certificate is installed, so make sure you upload it with the extension that matches its contents.
+
+| Extension | What it is | Installs as | Platform | Password |
+|---|---|---|---|---|
+| `.crt` `.cer` | A CA or server certificate | Trusted CA certificate | Android, iOS | Not used |
+| `.pfx` | A PKCS#12 bundle containing a private key and its certificate chain | Client identity, granted to the app under test | Android, iOS | Required at upload |
+| `.mobileconfig` | An Apple configuration profile | Installed profile | iOS only | Not used |
+
+**Constraints**
+
+| | |
+|---|---|
+| **Device type** | Real devices only (`isRealMobile: true`) |
+| **Platforms** | Android and iOS |
+| **Session types** | App Automation, App Testing (Manual) |
+| **Certificates per session request** | Up to 3 |
+| **Maximum file size** | 15 MB per certificate |
+| **Capability** | `customCertificates` |
+
+:::note Enablement Required
+Certificate Injection is enabled per organization. If your session request returns *"your organization is not allowed to use customCertificates"*, the feature is not yet switched on for your account.
+
+To unlock this feature, please contact your <BrandName /> support representative, reach out to our <span className="doc__lt" onClick={() => window.openLTChatWidget()}>**[24×7 Chat Support]**</span>, or email us at **support@testmuai.com**.
+:::
+
+:::warning
+The following are rejected when you request the session, instead of being ignored silently:
+
+- **Virtual devices and emulators.** The capability requires `isRealMobile: true`.
+- **Real device browser automation.** Certificates apply to app sessions only.
+:::
+
+---
+
+## Step 1: Upload the Certificate
+
+Upload the file to the media upload endpoint with `type=cert`, using your <BrandName /> username and access key for authentication. Uploaded certificates are saved to your account, so you only need to upload each certificate once.
+
+<Tabs className="docs__val">
+  <TabItem value="ca-cert" label="CA Certificate" default>
+
+Upload a `.crt`, `.cer`, or `.mobileconfig` file. No password is involved.
+
+<div className="lambdatest__codeblock">
+<CodeBlock className="language-bash">
+{`curl -u "${YOUR_LAMBDATEST_USERNAME()}:${YOUR_LAMBDATEST_ACCESS_KEY()}" \\
+  -X POST "https://api.lambdatest.com/mfs/v1.0/media/upload" \\
+  -F "media_file=@/Users/macuser/Downloads/corp-root-ca.crt" \\
+  -F "type=cert"`}
+</CodeBlock>
+</div>
+
+  </TabItem>
+  <TabItem value="pfx" label="PKCS#12 Identity (.pfx)">
+
+For a PKCS#12 bundle, send the password along with the upload. The password is stored securely against the certificate and applied automatically in every session that uses it.
+
+<div className="lambdatest__codeblock">
+<CodeBlock className="language-bash">
+{`curl -u "${YOUR_LAMBDATEST_USERNAME()}:${YOUR_LAMBDATEST_ACCESS_KEY()}" \\
+  -X POST "https://api.lambdatest.com/mfs/v1.0/media/upload" \\
+  -F "media_file=@/Users/macuser/Downloads/client-identity.pfx" \\
+  -F "type=cert" \\
+  -F "password=$CERT_PASSWORD"`}
+</CodeBlock>
+</div>
+
+  </TabItem>
+</Tabs>
+
+**Request Parameters**
+
+| Parameter | Required | Description |
+|---|---|---|
+| `media_file` | Yes | The certificate file to upload from your local machine. |
+| `type` | Yes | Must be `cert` for certificate uploads. |
+| `password` | Only for `.pfx` | The password for the PKCS#12 bundle. Stored securely and reused automatically. |
+
+The response returns the `media_url` that you reference in your capabilities:
+
+```json
+{
+  "media_url": "lt://MEDIA9f2c4b18a7d54e3ba0c6f19d2e8b7c05",
+  "name": "corp-root-ca.crt",
+  "status": "success"
+}
+```
+
+Use this value as the `certificateId` in your capabilities. Both the full `lt://MEDIA...` form and the bare `MEDIA...` identifier are accepted.
+
+The file is validated before it is stored. If it cannot be parsed as a certificate, the upload is rejected immediately instead of failing later on a device.
+
+:::tip
+You can also upload and manage certificates from the **Certificates** section of the App Testing dashboard. Certificates uploaded there are also available to your automation sessions. See [Certificate Injection on Real Devices](/support/docs/certificate-injection-on-realdevice/) for details.
+:::
+
+---
+
+## Step 2: Set the `customCertificates` Capability
+
+Pass `customCertificates` inside `LT:Options` as an **array of objects**. Each entry requires a `certificateId`. The `password` field is optional and overrides the password stored at upload time.
+
+:::note `customCertificates` is not `acceptInsecureCerts`
+These two capabilities are easy to confuse and do very different things.
+
+- **`customCertificates`** changes the **device trust store**. Use it when the device itself must trust your certificate authority, or when your app must present a client identity. Real device app automation only.
+- **`acceptInsecureCerts`** is a standard W3C WebDriver capability that tells the **browser context** to proceed past an untrusted certificate. It installs nothing and does not touch the device trust store.
+
+If you are testing a native app against a private certificate authority, `customCertificates` is the one you want.
+:::
+
+| Key | Type | Required | Description |
+|---|---|---|---|
+| `customCertificates` | Array of objects | Yes | The certificates to install for this session. Maximum 3 entries. |
+| `certificateId` | String | Yes | The `media_url` returned by the upload API. Both the full `lt://MEDIA...` form and the bare `MEDIA...` identifier are accepted. |
+| `password` | String | No | Overrides the password stored with a `.pfx` certificate at upload time. |
+
+<Tabs className="docs__val">
+  <TabItem value="json" label="JSON" default>
+
+```json
+{
+  "LT:Options": {
+    "platformName": "Android",
+    "deviceName": "Pixel 7",
+    "platformVersion": "14",
+    "isRealMobile": true,
+    "app": "lt://APP1234567890",
+    //highlight-start
+    "customCertificates": [
+      { "certificateId": "MEDIA9f2c4b18a7d54e3ba0c6f19d2e8b7c05" },
+      {
+        "certificateId": "MEDIA4a71e0c93f6d48b2915ac8de7b04f6a1",
+        "password": "s3cret"
+      }
+    ]
+    //highlight-end
+  }
+}
+```
+
+  </TabItem>
+  <TabItem value="java" label="Java">
+
+```java
+Map<String, Object> caCert = new HashMap<>();
+caCert.put("certificateId", "MEDIA9f2c4b18a7d54e3ba0c6f19d2e8b7c05");
+
+Map<String, Object> identity = new HashMap<>();
+identity.put("certificateId", "MEDIA4a71e0c93f6d48b2915ac8de7b04f6a1");
+identity.put("password", System.getenv("CERT_PASSWORD"));
+
+ltOptions.put("isRealMobile", true);
+//highlight-next-line
+ltOptions.put("customCertificates", List.of(caCert, identity));
+
+capabilities.setCapability("LT:Options", ltOptions);
+```
+
+  </TabItem>
+  <TabItem value="python" label="Python">
+
+```python
+lt_options = {
+    "platformName": "iOS",
+    "deviceName": "iPhone 14",
+    "platformVersion": "17",
+    "isRealMobile": True,
+    "app": "lt://APP1234567890",
+    #highlight-start
+    "customCertificates": [
+        {"certificateId": "MEDIA9f2c4b18a7d54e3ba0c6f19d2e8b7c05"},
+        {"certificateId": "MEDIA4a71e0c93f6d48b2915ac8de7b04f6a1",
+         "password": os.environ["CERT_PASSWORD"]},
+    ],
+    #highlight-end
+}
+```
+
+  </TabItem>
+  <TabItem value="javascript" label="JavaScript">
+
+```js
+const capabilities = {
+  'LT:Options': {
+    platformName: 'Android',
+    deviceName: 'Galaxy S23',
+    platformVersion: '14',
+    isRealMobile: true,
+    app: 'lt://APP1234567890',
+    //highlight-start
+    customCertificates: [
+      { certificateId: 'MEDIA9f2c4b18a7d54e3ba0c6f19d2e8b7c05' },
+      { certificateId: 'MEDIA4a71e0c93f6d48b2915ac8de7b04f6a1',
+        password: process.env.CERT_PASSWORD },
+    ],
+    //highlight-end
+  },
+};
+```
+
+  </TabItem>
+  <TabItem value="yaml" label="YAML">
+
+```yaml
+customCertificates:
+  - certificateId: "MEDIA9f2c4b18a7d54e3ba0c6f19d2e8b7c05"
+  - certificateId: "MEDIA4a71e0c93f6d48b2915ac8de7b04f6a1"
+    password: "s3cret"
+```
+
+  </TabItem>
+</Tabs>
+
+:::note
+Capabilities are validated before a device is allocated. The session request fails with a `400` if an entry is malformed, a `certificateId` is missing, you specify more than three certificates, a format rule is broken, or an ID does not exist on your account. No session time or concurrency slot is used.
+:::
+
+---
+
+## Password Requirements
+
+- **`.pfx` bundles:** a password is **required when you upload the bundle**. In capabilities the `password` field is **optional** — omit it to use the stored password, or set it to override. If the bundle genuinely has no password, upload it with an empty string (`""`).
+- **`.crt`, `.cer`, and `.mobileconfig`:** the password field is not used.
+- A `password` set in the capability **takes precedence** over the one stored at upload time. This is useful when a bundle is reissued and you have not re-uploaded it yet.
+
+:::tip Handling PKCS#12 passwords
+Supply the password once at upload time and leave it out of your capabilities. It is stored securely and applied automatically in every session that uses the certificate.
+
+If you do pass it in capabilities, read it from an environment variable or your CI secret store instead of hardcoding it. Certificate passwords are redacted from session logs.
+:::
+
+---
+
+## Step 3: Read the Installation Result
+
+Certificates are installed **after the app is installed and before your test starts**. Each certificate reports its own status in the **session logs** on the Automation dashboard, so you can see exactly which ones installed successfully.
+
+:::info
+If a certificate fails to install, your session **does not fail**. The session starts and your test runs, so you can decide whether the missing certificate affects the scenario you are testing.
+:::
+
+---
+
+## What Happens on the Device
+
+<Tabs className="docs__val">
+  <TabItem value="android" label="Android" default>
+
+- A **CA certificate** is added to the device's user trust store, under a name derived from your filename. Existing trusted certificates on the device are not removed.
+- A **PKCS#12 identity** is installed into the device keystore and then granted to the app under test. On Android, an app cannot access a key unless it has been granted access to it.
+
+:::warning Android Apps Must Opt In to User CAs
+Since **Android 7**, an app trusts user-installed CA certificates only if its network security configuration allows it. Installing the CA on the device is **not enough on its own**. If your app uses the default configuration, it will still reject the connection.
+
+In the build you are testing, add a `network_security_config.xml` file that trusts the `user` certificate store:
+
+```xml
+<network-security-config>
+    <base-config>
+        <trust-anchors>
+            <certificates src="system" />
+            <certificates src="user" />
+        </trust-anchors>
+    </base-config>
+</network-security-config>
+```
+:::
+
+  </TabItem>
+  <TabItem value="ios" label="iOS">
+
+- Certificates are delivered to the device as a **managed configuration profile**, installed and trusted without any manual step on the device.
+- A `.mobileconfig` file keeps its own identifier and payload, so a profile that you have already validated in your own environment behaves the same way here.
+
+:::note
+Installation is asynchronous on iOS, so a certificate may briefly report as **pending**. This means the device management channel has accepted it, but the device has not confirmed it yet. The status updates automatically shortly after the session starts.
+:::
+
+  </TabItem>
+</Tabs>
+
+:::note
+Each additional certificate increases session start time slightly, because every certificate is installed and confirmed before your test begins.
+:::
+
+---
+
+## Limits and Validation Rules
+
+| Rule | Value | What happens if you exceed it |
+|---|---|---|
+| Certificates per session request | **3** | Session request rejected with `400` |
+| Certificate file size | **15 MB** | Upload rejected |
+| `certificateId` | Required on every entry | Session request rejected with `400` |
+| Password on `.pfx` | Required at upload; optional in capabilities | A wrong password fails injection and the session is refused |
+| `isRealMobile` | Must be `true` | Session request rejected with `400` |
+| Browser automation | Not supported | Session request rejected with `400` |
+| Organization entitlement | Must be enabled | Session request rejected with `400` |
+
+---
+
+## FAQs
+
+**Q: My CA installs successfully but the app still rejects the connection. Why?**
+
+On Android, this is almost always caused by the network security configuration. Since Android 7, apps do not trust user-installed CA certificates unless their `network_security_config.xml` explicitly allows it. The certificate is installed on the device, but your app is not configured to trust it.
+
+Build a test variant that trusts the `user` certificate store, and use that build for these runs.
+
+**Q: Does a failed certificate fail my test?**
+
+No. The session starts and your test runs regardless. Each certificate reports its own status, so you can see which ones installed and decide whether a missing certificate affects the scenario you are testing.
+
+**Q: Will another customer's session see my certificate?**
+
+No. Certificates are installed for a specific session on a specific device, and are removed when that session ends, including when a session times out or is stopped early. Each device is verified before it returns to the device pool. If a certificate is still present, the device is held back instead of being allocated to another user.
+
+---
+
+## Additional Links
+
+- [Certificate Injection on Real Devices (Manual App Testing)](/support/docs/certificate-injection-on-realdevice/)
+- [Desired Capabilities in Appium](/support/docs/desired-capabilities-in-appium/)
+- [Uploading Files and Media on Real Devices](/support/docs/upload-media/)
+
+---
+
+Need help with something this page does not cover, such as an unlisted certificate format, more than three certificates in a session, or a failed installation? Reach out to our <span className="doc__lt" onClick={() => window.openLTChatWidget()}>**[24×7 Chat Support]**</span> or email **support@testmuai.com**.
diff --git a/docs/certificate-injection-on-realdevice.md b/docs/certificate-injection-on-realdevice.md
new file mode 100644
index 000000000..bb2d87468
--- /dev/null
+++ b/docs/certificate-injection-on-realdevice.md
@@ -0,0 +1,252 @@
+---
+id: certificate-injection-on-realdevice
+title: Certificate Injection on Real Devices
+sidebar_label: Certificate Injection
+description: Upload and install custom CA certificates and client identities on TestMu AI real devices during manual app testing sessions to test apps that use SSL pinning, self-signed certificates, or mutual TLS.
+keywords:
+  - certificate injection
+  - custom certificates
+  - install certificates
+  - ssl pinning
+  - self signed certificate
+  - mutual tls
+  - client certificate
+  - ca certificate
+  - pkcs12 pfx
+  - mobileconfig
+  - manual app testing
+  - app live
+  - testmu ai
+  - real devices
+url: https://www.testmuai.com/support/docs/certificate-injection-on-realdevice/
+site_name: TestMu AI
+slug: certificate-injection-on-realdevice/
+canonical: https://www.testmuai.com/support/docs/certificate-injection-on-realdevice/
+---
+
+import Tabs from '@theme/Tabs';
+import TabItem from '@theme/TabItem';
+import RealDeviceTag from '../src/component/realDevice';
+import BrandName, { BRAND_URL } from '@site/src/component/BrandName';
+
+
+<script type="application/ld+json"
+      dangerouslySetInnerHTML={{ __html: JSON.stringify({
+       "@context": "https://schema.org",
+        "@type": "BreadcrumbList",
+        "itemListElement": [{
+          "@type": "ListItem",
+          "position": 1,
+          "name": "Home",
+          "item": BRAND_URL
+        },{
+          "@type": "ListItem",
+          "position": 2,
+          "name": "Support",
+          "item": `${BRAND_URL}/support/docs/`
+        },{
+          "@type": "ListItem",
+          "position": 3,
+          "name": "Certificate Injection on Real Devices",
+          "item": `${BRAND_URL}/support/docs/certificate-injection-on-realdevice/`
+        }]
+      })
+    }}
+></script>
+
+<RealDeviceTag value="Real Device" />
+
+Many apps connect to servers that use certificates issued by a private or corporate certificate authority. Some apps also pin a **self-signed certificate**, or present a **client certificate** to authenticate themselves before a server will respond. On a standard device, these connections fail because the device does not trust your organization's certificates.
+
+<BrandName />'s **Certificate Injection** allows you to upload your own certificates and install them on a real device during a manual App Testing session. Your app then behaves on the <BrandName /> cloud exactly as it does on your internal network. Certificates are installed for a single session and are removed when the session ends.
+
+---
+
+## Use Cases
+
+- Test apps that use **self-signed certificates** in development and staging environments.
+- Verify app behavior when **SSL pinning** is enabled, and debug related network issues.
+- Test **mutual TLS (mTLS)** login flows where your app must present a client certificate.
+- Access **internal or pre-production endpoints** signed by a corporate certificate authority, without disabling TLS validation in your build.
+
+---
+
+## Availability
+
+| | |
+|---|---|
+| **Device type** | Real devices only |
+| **Platforms** | Android and iOS |
+| **Session types** | App Testing (Manual) and App Automation |
+| **Certificates at session launch** | Up to 3 |
+| **Maximum file size** | 15 MB per certificate |
+
+:::note Enablement Required
+Certificate Injection is enabled per organization. If the **Certificates** section is not visible on your dashboard, the feature is not yet switched on for your account.
+
+To unlock this feature, please contact your <BrandName /> support representative, reach out to our <span className="doc__lt" onClick={() => window.openLTChatWidget()}>**[24×7 Chat Support]**</span>, or email us at **support@testmuai.com**.
+:::
+
+:::warning
+Certificate Injection applies to **app testing** sessions on **real devices**. It is not available on virtual devices or emulators, and it is not supported in real device **browser** testing sessions.
+:::
+
+---
+
+## Supported Certificate Formats
+
+The file extension determines how a certificate is installed, so make sure you upload it with the extension that matches its contents.
+
+| Extension | What it is | Installs as | Platform | Password |
+|---|---|---|---|---|
+| `.crt` `.cer` | A CA or server certificate | Trusted CA certificate | Android, iOS | Not used |
+| `.pfx` | A PKCS#12 bundle containing a private key and its certificate chain | Client identity, granted to the app under test | Android, iOS | Required |
+| `.mobileconfig` | An Apple configuration profile | Installed profile | iOS only | Not used |
+
+:::note
+Android does not have an equivalent of an Apple configuration profile, so a `.mobileconfig` file can only be used in an iOS session.
+:::
+
+---
+
+## Upload Certificates Before a Test Session
+
+Certificates are saved to your account and reused across sessions, so you only need to upload each certificate once.
+
+**Step 1:** Open the **App Testing** dashboard and select the app and device you want to launch.
+
+**Step 2:** In the left panel, expand the **Certificates** section. It appears below your app sources: **Uploaded Apps**, **Install from Play Store**, and **Install from Firebase**.
+
+**Step 3:** Click **Upload** and select the certificate file from your machine. If you are uploading a `.pfx` bundle, enter its password. The password is stored securely against the certificate, so you do not need to enter it again for later sessions.
+
+**Step 4:** Turn on the **toggle** next to each certificate you want installed for this session. You can select up to **3 certificates at launch**. If you need more than three on the device, install the additional ones from the in-session **Certificates** panel after the session starts.
+
+**Step 5:** Click **Start** to launch the session. The selected certificates are installed on the device as the session starts.
+
+![Upload and select certificates on the App Testing launch page](../assets/images/real-device-app-testing/Certificate-Injection/certificates-launch-page.webp)
+
+Each certificate in the list shows the platforms it applies to, what it installs as (for example, **Client identity** for a `.pfx` bundle), and when it was uploaded. Use **Search certificates** to find a certificate quickly.
+
+:::info
+If a certificate fails to install, the session **still starts**. Each certificate reports its own status, so you can check which ones installed successfully before you begin testing.
+:::
+
+---
+
+## Manage Certificates During a Test Session
+
+You can also manage certificates inside a running session. This allows you to check which certificates are installed, install one that you did not enable at launch, and upload a new certificate without restarting the session.
+
+**Step 1:** In the session sidebar, open **Android Settings** (or **iOS Settings** on an iOS device) and click **Certificates**. The badge shows how many certificates are currently installed on the device.
+
+![Open Certificates from Android Settings in the session sidebar](../assets/images/real-device-app-testing/Certificate-Injection/session-android-settings-certificates.webp)
+
+**Step 2:** The **Certificates** panel lists your uploaded certificates, with an **Installed** or **Not installed** status next to each one.
+
+**Step 3:** To install a certificate that is not yet on the device, click the **⋯** menu next to it and select **Install certificate**.
+
+**Step 4:** To add a new certificate, click **Upload** at the bottom of the panel and select the file. The certificate is added to your account and can be installed immediately.
+
+![Install or upload certificates from the in-session Certificates panel](../assets/images/real-device-app-testing/Certificate-Injection/session-certificates-panel.webp)
+
+:::tip
+Use the **Search** field at the top of the panel to find a certificate quickly if your account has a long list.
+:::
+
+---
+
+## Delete Uploaded Certificates
+
+Certificates remain on your account until you remove them. To delete a certificate, open the **Certificates** section on the App Testing dashboard, select the certificate, and click **Delete**.
+
+Deleting a certificate only removes it from your account. It does not affect a session that is already running.
+
+---
+
+## What Happens on the Device
+
+The behavior differs by platform, because Android and iOS handle certificate trust differently.
+
+<Tabs className="docs__val">
+  <TabItem value="android" label="Android" default>
+
+- A **CA certificate** is added to the device's user trust store, under a name derived from your filename. Existing trusted certificates on the device are not removed.
+- A **PKCS#12 identity** is installed into the device keystore and then granted to the app under test. On Android, an app cannot access a key unless it has been granted access to it.
+
+To confirm that a CA certificate is present, go to **Settings** > **Security** > **Encryption & credentials** > **Trusted credentials** > **User** on the device during your session.
+
+:::warning Android Apps Must Opt In to User CAs
+Since **Android 7**, an app trusts user-installed CA certificates only if its network security configuration allows it. Installing the CA on the device is **not enough on its own**. If your app uses the default configuration, it will still reject the connection.
+
+In the build you are testing, add a `network_security_config.xml` file that trusts the `user` certificate store:
+
+```xml
+<network-security-config>
+    <base-config>
+        <trust-anchors>
+            <certificates src="system" />
+            <certificates src="user" />
+        </trust-anchors>
+    </base-config>
+</network-security-config>
+```
+:::
+
+  </TabItem>
+  <TabItem value="ios" label="iOS">
+
+- Certificates are delivered to the device as a **managed configuration profile**, installed and trusted without any manual step on the device.
+- A `.mobileconfig` file keeps its own identifier and payload, so a profile that you have already validated in your own environment behaves the same way here.
+
+To confirm that a profile is present, go to **Settings** > **General** > **VPN & Device Management** on the device during your session.
+
+:::note
+Installation is asynchronous on iOS, so a certificate may briefly show as **pending**. This means the device management channel has accepted it, but the device has not confirmed it yet. The status updates automatically shortly after the session starts.
+:::
+
+  </TabItem>
+</Tabs>
+
+---
+
+## Limits and Rules
+
+| Rule | Value |
+|---|---|
+| Certificates at session launch | **3**. Install further certificates from the in-session **Certificates** panel |
+| Certificate file size | **15 MB** |
+| Device type | Real devices only. Not available on virtual devices or emulators |
+| Session type | App testing sessions only. Not supported in real device browser testing |
+| Password on `.pfx` | Required at upload time |
+| `.mobileconfig` | iOS sessions only |
+| Organization entitlement | Must be enabled for your account |
+
+---
+
+## FAQs
+
+**Q: My CA installs successfully but the app still rejects the connection. Why?**
+
+On Android, this is almost always caused by the network security configuration. Since Android 7, apps do not trust user-installed CA certificates unless their `network_security_config.xml` explicitly allows it. The certificate is installed on the device, but your app is not configured to trust it.
+
+Build a test variant that trusts the `user` certificate store, and use that build for these sessions.
+
+**Q: One of my certificates shows as Not installed. What now?**
+
+Open the **Certificates** panel from the session sidebar, click the **⋯** menu next to it, and select **Install certificate**. If it still fails, the most common cause for a `.pfx` bundle is an incorrect password, which prevents the identity from being read. Verify the password by opening the bundle on your local machine, then re-upload the certificate with the correct password.
+
+**Q: Will another customer's session see my certificate?**
+
+No. Certificates are installed for a specific session on a specific device, and are removed when that session ends, including when a session times out or is stopped early. Each device is verified before it returns to the device pool. If a certificate is still present, the device is held back instead of being allocated to another user.
+
+---
+
+## Additional Links
+
+- [Certificate Injection in App Automation on Real Devices](/support/docs/certificate-injection-appautomation/)
+- [App Testing on Real Devices](/support/docs/app-testing-on-real-devices/)
+- [How to Use Testing Tools in a Session](/support/docs/how-to-use-testing-tools-in-session/)
+
+---
+
+Need help with something this page does not cover, such as an unlisted certificate format, more than three certificates in a session, or a failed installation? Reach out to our <span className="doc__lt" onClick={() => window.openLTChatWidget()}>**[24×7 Chat Support]**</span> or email **support@testmuai.com**.
diff --git a/sidebars.js b/sidebars.js
index 75272d527..89785c765 100644
--- a/sidebars.js
+++ b/sidebars.js
@@ -1873,6 +1873,7 @@ module.exports = {
               "devtools-on-real-devices-app",
               "set-date-time-hour-format-real-devices",
               "device-passcode-on-realdevice",
+              "certificate-injection-on-realdevice",
               "assistive-touch-on-real-ios-devices",
               "dark-mode-on-real-devices",
               "low-power-mode-on-real-devices",
@@ -2345,6 +2346,7 @@ module.exports = {
               "live-debug-in-app-automation",
               "appium-date-and-time",
               "device-passcode-appautomation",
+              "certificate-injection-appautomation",
               "set-device-dark-mode",
               "smart-heal-appium",
               "apple-pay-auto",