diff --git a/docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx b/docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx
index a7f3dd4ce5..765dfbf365 100644
--- a/docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx
+++ b/docs/integrations/platforms/kubernetes/infisical-secret-crd.mdx
@@ -970,6 +970,13 @@ Please refer to the [templating functions documentation](/integrations/platforms
 
 </Accordion>
 
+<Accordion title="managedKubeSecretReferences[].template.metadata">
+  Define custom labels and annotations for the managed Kubernetes secret. This allows you to specify metadata that should be applied to the managed secret separately from the InfisicalSecret itself.
+
+  For detailed information on how metadata propagation works and examples, see the [Propagating Labels & Annotations](#propagating-labels-&-annotations) section.
+
+</Accordion>
+
 ### Operator Managed ConfigMaps
 
 The managed config map properties specify where to store the secrets retrieved from your Infisical project. Config maps can be used to store **non-sensitive** data, such as application configuration variables.
@@ -1078,6 +1085,13 @@ Please refer to the [templating functions documentation](/integrations/platforms
 
 </Accordion>
 
+<Accordion title="managedKubeConfigMapReferences[].template.metadata">
+  Define custom labels and annotations for the managed Kubernetes ConfigMap. This allows you to specify metadata that should be applied to the managed ConfigMap separately from the InfisicalSecret itself.
+
+  This field works the same way as `template.metadata` for managed secrets. For detailed information on how metadata propagation works and examples, see the [Propagating Labels & Annotations](#propagating-labels-&-annotations) section.
+
+</Accordion>
+
 ## Applying CRD
 
 Once you have configured the InfisicalSecret CRD with the required fields, you can apply it to your cluster.
@@ -1564,10 +1578,13 @@ stringData:
 
 ## Propagating Labels & Annotations
 
-The operator will transfer all labels & annotations present on the `InfisicalSecret` CRD to the managed Kubernetes secret to be created.
-Thus, if a specific label is required on the resulting secret, it can be applied as demonstrated in the following example:
+The operator provides flexible options for managing labels and annotations on managed Kubernetes secrets.
+
+<Accordion title="Default Behavior (Without template.metadata)">
+  By default, the operator will transfer all labels & annotations present on the `InfisicalSecret` to the managed Kubernetes secret to be created.
+
+  ### Example
 
-<Accordion title="Example propagation">
   ```yaml
   apiVersion: secrets.infisical.com/v1alpha1
   kind: InfisicalSecret
@@ -1578,28 +1595,95 @@ Thus, if a specific label is required on the resulting secret, it can be applied
     annotations:
       example.com/annotation-to-be-passed-to-managed-secret: "sample-value"
   spec:
-    ..
     authentication:
-      ...
+      # ... auth config ...
     managedKubeSecretReferences:
-      ...
+      - secretName: managed-token
+        secretNamespace: default
   ```
 
-This would result in the following managed secret to be created:
+  This would result in the following managed secret to be created:
 
-```yaml
-apiVersion: v1
-data: ...
-kind: Secret
-metadata:
-  annotations:
-    example.com/annotation-to-be-passed-to-managed-secret: sample-value
-    secrets.infisical.com/version: W/"3f1-ZyOSsrCLGSkAhhCkY2USPu2ivRw"
-  labels:
-    label-to-be-passed-to-managed-secret: sample-value
-  name: managed-token
-  namespace: default
-type: Opaque
-```
+  ```yaml
+  apiVersion: v1
+  data: ...
+  kind: Secret
+  metadata:
+    annotations:
+      example.com/annotation-to-be-passed-to-managed-secret: sample-value
+      secrets.infisical.com/version: W/"3f1-ZyOSsrCLGSkAhhCkY2USPu2ivRw"
+    labels:
+      label-to-be-passed-to-managed-secret: sample-value
+    name: managed-token
+    namespace: default
+  type: Opaque
+  ```
+</Accordion>
+
+<Accordion title="Custom Metadata (With template.metadata)">
+  When you specify `template.metadata` in your template configuration, you have full control over which labels and annotations are applied to the managed secret:
+
+  - Labels and annotations from `template.metadata` are used exclusively on the managed secret
+  - InfisicalSecret labels and annotations are NOT propagated to the managed secret
+  - This allows you to keep InfisicalSecret-specific metadata separate from the managed secret metadata
+
+  <Tip>
+    To prevent propagation while using `template.metadata`, pass empty objects for labels and/or annotations:
+    
+    ```yaml
+    template:
+      metadata:
+        labels: {}
+        annotations: {}
+    ```
+  </Tip>
+
+  ### Example
+
+  ```yaml
+  apiVersion: secrets.infisical.com/v1alpha1
+  kind: InfisicalSecret
+  metadata:
+    name: infisicalsecret-with-template-metadata
+    labels:
+      managed-by: infisical-operator
+    annotations:
+      example.com/cr-specific: "metadata"
+  spec:
+    authentication:
+      # ... auth config ...
+    managedKubeSecretReferences:
+      - secretName: managed-secret-with-custom-metadata
+        secretNamespace: default
+        template:
+          includeAllSecrets: true
+          metadata:
+            labels:
+              app: my-application
+              environment: production
+              tier: backend
+            annotations:
+              secret.example.com/description: "Production database credentials"
+              secret.example.com/owner: "platform-team"
+  ```
+
+  This would result in the following managed secret to be created:
+
+  ```yaml
+  apiVersion: v1
+  data: ...
+  kind: Secret
+  metadata:
+    annotations:
+      secret.example.com/description: "Production database credentials"
+      secret.example.com/owner: "platform-team"
+    labels:
+      app: my-application
+      environment: production
+      tier: backend
+    name: managed-secret-with-custom-metadata
+    namespace: default
+  type: Opaque
+  ```
 
 </Accordion>