diff --git a/modules/hcp-release-notes-fixed-issues.adoc b/modules/hcp-release-notes-fixed-issues.adoc
index 7b74db23f742..268bd72491ec 100644
--- a/modules/hcp-release-notes-fixed-issues.adoc
+++ b/modules/hcp-release-notes-fixed-issues.adoc
@@ -46,4 +46,8 @@ The following issues are fixed for this release:
 
 * Before this update, a race condition in `VolumeSnapshot` processing where a snapshot was deleted between listing and retrieving was treated as an unrecoverable error, ending the processing of remaining snapshots. As a consequence, intermittent backup failures (about 25% of scheduled backups) were marked as `PartiallyFailed` with missing etcd PVC data. With this release, deleted snapshots are gracefully skipped instead of treated as unrecoverable errors, allowing the remaining snapshots to be processed normally. As a result, backups are completed successfully even when snapshot cleanup races with plugin processing. (link:https://redhat.atlassian.net/browse/OCPBUGS-75913[OCPBUGS-75913])
 
-* Before this update, when the scale-from-zero feature was enabled in {aws-short} and a node pool used the `InPlace` node upgrade type with autoscaling set to `min=0`, the scale-from-zero implementation did not support the `InPlace` upgrade strategy. The original implementation used a machine deployment controller approach that only worked with the `Replace` upgrade strategy. As a consequence, new workloads did not trigger node pool scale-up from zero when using the `InPlace` upgrade type, preventing nodes from being created even when pods were pending. With this release, the scale-from-zero implementation uses a generic provider pattern that works with all upgrade types. As a result, node pools that use the `InPlace` upgrade type can scale up from zero when workload demands require additional capacity. The autoscaler correctly provisions nodes regardless of the upgrade strategy. (link:https://redhat.atlassian.net/browse/OCPBUGS-70320[OCPBUGS-70320])
\ No newline at end of file
+* Before this update, when the scale-from-zero feature was enabled in {aws-short} and a node pool used the `InPlace` node upgrade type with autoscaling set to `min=0`, the scale-from-zero implementation did not support the `InPlace` upgrade strategy. The original implementation used a machine deployment controller approach that only worked with the `Replace` upgrade strategy. As a consequence, new workloads did not trigger node pool scale-up from zero when using the `InPlace` upgrade type, preventing nodes from being created even when pods were pending. With this release, the scale-from-zero implementation uses a generic provider pattern that works with all upgrade types. As a result, node pools that use the `InPlace` upgrade type can scale up from zero when workload demands require additional capacity. The autoscaler correctly provisions nodes regardless of the upgrade strategy. (link:https://redhat.atlassian.net/browse/OCPBUGS-70320[OCPBUGS-70320])
+
+* Before this update, a race condition in the `globalps` controller skipped labeling new nodes, causing a delay in `global-pull-secret-syncer` pod scheduling. As a consequence, users experienced image pull failures from private registries on new nodes. With this release, the scheduling delay is resolved, fixing the race condition in the Hosted Cluster Config Operator. As a result, the `global-pull-secret-syncer` pod now schedules immediately on new nodes, ensuring timely access to private images. (link:https://redhat.atlassian.net/browse/OCPBUGS-77254[OCPBUGS-77254])
+
+* Before this update, the `IsCloudAPI` method for the `Konnectivity` proxy did not include {aws-first} ISO region domain suffixes, such as `.c2s.ic.gov`, `.hci.ic.gov`, or `.sc2s.sgov.gov` in its cloud API detection lists. As a consequence, the Ingress Operator could not add {aws-short} ISO domains to the `NO_PROXY` list, blocking direct communication with endpoints. With this release, the {aws-short} ISO suffixes are added to the `IsCloudAPI` detection list. As a result, the `Konnectivity` proxy correctly identifies the {aws-short} ISO region endpoints as cloud APIs, so that the Ingress Operator can route traffic to those domains directly. (link:https://redhat.atlassian.net/browse/OCPBUGS-85779[OCPBUGS-85779])
diff --git a/modules/hcp-release-notes-known-issues.adoc b/modules/hcp-release-notes-known-issues.adoc
index 828506313eeb..cee30b3d7cd3 100644
--- a/modules/hcp-release-notes-known-issues.adoc
+++ b/modules/hcp-release-notes-known-issues.adoc
@@ -2,7 +2,7 @@
 [id="hcp-release-notes-known-issues_{context}"]
 = Known issues
 
-This section includes several known issues for {product-title} {product-version}.
+This section includes several known issues for {hcp} for {product-title} {product-version}.
 
 * If the annotation and the `ManagedCluster` resource name do not match, the {mce} console displays the cluster as `Pending import`. The cluster cannot be used by the {mce-short}. The same issue happens when there is no annotation and the `ManagedCluster` name does not match the `Infra-ID` value of the `HostedCluster` resource.