diff --git a/_topic_maps/_topic_map.yml b/_topic_maps/_topic_map.yml
index 6eebda55cd1c..1d508464eeef 100644
--- a/_topic_maps/_topic_map.yml
+++ b/_topic_maps/_topic_map.yml
@@ -3539,11 +3539,11 @@ Topics:
     Dir: security
     Topics:
     - Name: Security basics
-      File: telco-security-basics
+      File: security-basics
     - Name: Host security
-      File: telco-security-host-sec
+      File: security-host-sec
     - Name: Security context constraints
-      File: telco-security-sec-context-constraints
+      File: security-sec-context-constraints
 ---
 Name: Specialized hardware and driver enablement
 Dir: hardware_enablement
diff --git a/edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc b/edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
new file mode 100644
index 000000000000..af523b4f79e4
--- /dev/null
+++ b/edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
@@ -0,0 +1,52 @@
+:_mod-docs-content-type: ASSEMBLY
+[id="security-basics"]
+= Security basics
+include::_attributes/common-attributes.adoc[]
+:context: security-basics
+
+toc::[]
+
+Security is a critical component of {product-title} deployments , particularly when running cloud-native applications. 
+
+You can enhance security for high-bandwidth network deployments by following key security considerations. By implementing these standards and best practices, you can strengthen security in most use cases.
+
+include::modules/security-rbac-overview.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../authentication/using-rbac.adoc#authorization-overview_using-rbac[Using RBAC to define and apply permissions]
+
+include::modules/security-sec-accounts-overview.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../authentication/understanding-and-creating-service-accounts.adoc#understanding-and-creating-service-accounts[Understanding and creating service accounts]
+
+include::modules/security-identity-prov-config.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../authentication/understanding-identity-provider.adoc#understanding-identity-provider[Understanding identity provider configuration]
+
+include::modules/security-replacing-kubeadmin-user.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../authentication/identity_providers/configuring-htpasswd-identity-provider.adoc#identity-provider-htpasswd-about_configuring-htpasswd-identity-provider[Configuring an htpasswd identity provider]
+
+include::modules/security-sec-considerations-telco.adoc[leveloffset=+1]
+
+include::modules/security-pod-sec-in-kub-and-ocp.adoc[leveloffset=+1]
+
+include::modules/security-infra.adoc[leveloffset=+1]
+
+include::modules/security-lifecycle-mgmnt.adoc[leveloffset=+1]
+
+[role="_additional-resources"]
+.Additional resources
+
+* xref:../../../edge_computing/day_2_core_cnf_clusters/updating/telco-update-welcome.adoc#[Upgrading a telco core CNF clusters]
diff --git a/edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc b/edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc
similarity index 54%
rename from edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc
rename to edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc
index 0901f1f475bd..8b4ca6f5b7f0 100644
--- a/edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc
+++ b/edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc
@@ -1,27 +1,27 @@
 :_mod-docs-content-type: ASSEMBLY
-[id="telco-security-host-sec"]
+[id="security-host-sec"]
 = Host security
 include::_attributes/common-attributes.adoc[]
-:context: telco-security-host-sec
+:context: security-host-sec
 
 toc::[]
 
-include::modules/telco-security-rhcos-overview.adoc[leveloffset=+1]
+include::modules/security-rhcos-overview.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
 * xref:../../../architecture/architecture-rhcos.adoc#rhcos-about_architecture-rhcos[About RHCOS]
 
-* xref:../../../architecture/architecture-rhcos.adoc[Red Hat Enterprise Linux CoreOS (RHCOS)].
+* xref:../../../architecture/architecture-rhcos.adoc[Red Hat Enterprise Linux CoreOS (RHCOS)]
 
-* xref:../../../edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc#telco-security-linux-capabilities-overview_telco-security-host-sec[Linux capabilities].
+* xref:../../../edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc#security-linux-capabilities-overview_security-host-sec[Linux capabilities]
 
-include::modules/telco-security-command-line-host-access.adoc[leveloffset=+1]
+include::modules/security-command-line-host-access.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
-* xref:../../../support/troubleshooting/investigating-pod-issues.adoc#starting-debug-pods-with-root-access_investigating-pod-issues[Starting debug pods with root access].
+* xref:../../../support/troubleshooting/investigating-pod-issues.adoc#starting-debug-pods-with-root-access_investigating-pod-issues[Starting debug pods with root access]
 
-include::modules/telco-security-linux-capabilities-overview.adoc[leveloffset=+1]
+include::modules/security-linux-capabilities-overview.adoc[leveloffset=+1]
diff --git a/edge_computing/day_2_core_cnf_clusters/security/telco-security-sec-context-constraints.adoc b/edge_computing/day_2_core_cnf_clusters/security/security-sec-context-constraints.adoc
similarity index 98%
rename from edge_computing/day_2_core_cnf_clusters/security/telco-security-sec-context-constraints.adoc
rename to edge_computing/day_2_core_cnf_clusters/security/security-sec-context-constraints.adoc
index beee9df8a9dc..d0dfe2295180 100644
--- a/edge_computing/day_2_core_cnf_clusters/security/telco-security-sec-context-constraints.adoc
+++ b/edge_computing/day_2_core_cnf_clusters/security/security-sec-context-constraints.adoc
@@ -1,8 +1,8 @@
 :_mod-docs-content-type: ASSEMBLY
-[id="telco-security-sec-context-constraints"]
+[id="security-sec-context-constraints"]
 = Security context constraints
 include::_attributes/common-attributes.adoc[]
-:context: telco-security-sec-context-constraints
+:context: security-sec-context-constraints
 :imagesdir: images
 
 toc::[]
@@ -43,10 +43,13 @@ You can use the following basic SCCs:
 The `restricted-v2` SCC is the most restrictive SCC provided by a new installation and is used by default for authenticated users. It aligns with Pod Security Admission (PSA) restrictions and improves security, as the original `restricted` SCC is less restrictive. It also helps transition from the original SCCs to v2 across multiple releases. Eventually, the original SCCs get deprecated. Therefore, it is recommended to use the `restricted-v2` SCC.
 
 You can examine the `restricted-v2` SCC by running the following command:
++
 [source,terminal]
 ----
 $ oc describe scc restricted-v2
 ----
+
++
 .Example output
 [source,terminal]
 ----
diff --git a/edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc b/edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
deleted file mode 100644
index 1bf93409645f..000000000000
--- a/edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+++ /dev/null
@@ -1,56 +0,0 @@
-:_mod-docs-content-type: ASSEMBLY
-[id="telco-security-basics"]
-= Security basics
-include::_attributes/common-attributes.adoc[]
-:context: telco-security-basics
-
-toc::[]
-
-Security is a critical component of telecommunications deployments on {product-title}, particularly when running cloud-native network functions (CNFs). 
-
-You can enhance security for high-bandwidth network deployments in telecommunications (telco) environments by following key security considerations. By implementing these standards and best practices, you can strengthen security in telco-specific use cases.
-
-include::modules/telco-security-rbac-overview.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../authentication/using-rbac.adoc#authorization-overview_using-rbac[Using RBAC to define and apply permissions]
-
-include::modules/telco-security-sec-accounts-overview.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../authentication/understanding-and-creating-service-accounts.adoc[Understanding and creating service accounts]
-
-include::modules/telco-security-identity-prov-config.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../authentication/understanding-identity-provider.adoc[Understanding identity provider configuration]
-
-include::modules/telco-security-replacing-kubeadmin-user.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-* xref:../../../authentication/identity_providers/configuring-htpasswd-identity-provider.adoc#identity-provider-htpasswd-about_configuring-htpasswd-identity-provider[About htpasswd authentication]
-
-include::modules/telco-security-sec-considerations-telco.adoc[leveloffset=+1]
-
-include::modules/telco-security-pod-sec-in-kub-and-ocp.adoc[leveloffset=+1]
-
-include::modules/telco-security-key-areas-for-cnf-deploy.adoc[leveloffset=+1]
-
-include::modules/telco-security-infra.adoc[leveloffset=+1]
-
-include::modules/telco-security-lifecycle-mgmnt.adoc[leveloffset=+1]
-
-[role="_additional-resources"]
-.Additional resources
-
-xref:../../../edge_computing/day_2_core_cnf_clusters/updating/telco-update-welcome.adoc[Upgrading a telco core CNF clusters]
-
-include::modules/telco-security-evolu-nf-to-cnf.adoc[leveloffset=+1]
diff --git a/modules/telco-security-command-line-host-access.adoc b/modules/security-command-line-host-access.adoc
similarity index 93%
rename from modules/telco-security-command-line-host-access.adoc
rename to modules/security-command-line-host-access.adoc
index 520632bbb36b..457b3e3665be 100644
--- a/modules/telco-security-command-line-host-access.adoc
+++ b/modules/security-command-line-host-access.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc
+// * edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="telco-security-command-line-host-access_{context}"]
+[id="security-command-line-host-access_{context}"]
 = Command-line host access
 
 Direct access to a host must be restricted to avoid modifying the host or accessing pods that should not be accessed. For users who need direct access to a host, it is recommended to use an external authenticator, like SSSD with LDAP, to manage access. This helps maintain consistency across the cluster through the Machine Config Operator.
diff --git a/modules/telco-security-identity-prov-config.adoc b/modules/security-identity-prov-config.adoc
similarity index 90%
rename from modules/telco-security-identity-prov-config.adoc
rename to modules/security-identity-prov-config.adoc
index bf4537f08a7d..d20bb63c8897 100644
--- a/modules/telco-security-identity-prov-config.adoc
+++ b/modules/security-identity-prov-config.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="telco-security-identity-prov-config_{context}"]
+[id="security-identity-prov-config_{context}"]
 = Identity provider configuration
 
 Configuring an identity provider is the first step in setting up users on the cluster. You can manage groups at the organizational level by using an identity provider. 
diff --git a/modules/security-infra.adoc b/modules/security-infra.adoc
new file mode 100644
index 000000000000..a6eae6d12388
--- /dev/null
+++ b/modules/security-infra.adoc
@@ -0,0 +1,11 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="security-infra_{context}"]
+= Bare metal-based infrastructure
+
+Hardware requirements:: In several industries, such as telco and finance, clusters are primarily built on bare-metal hardware. This means that the (op-system-first) operating system is installed directly on the physical machines, without using virtual machines. This reduces network connectivity complexity, minimizes latency, and optimizes CPU usage for applications.
+
+Network requirements:: Networks in these industries sometimes require much higher bandwidth compared to standard IT networks. For example, Telco networks commonly use dual-port 25 GB connections or 100 GB network interface cards (NICs) to handle massive data throughput. Security is critical, requiring encrypted connections and secure endpoints to protect sensitive personal data.
\ No newline at end of file
diff --git a/modules/telco-security-lifecycle-mgmnt.adoc b/modules/security-lifecycle-mgmnt.adoc
similarity index 83%
rename from modules/telco-security-lifecycle-mgmnt.adoc
rename to modules/security-lifecycle-mgmnt.adoc
index b3fb420bcb3c..e4ab2d2eeeff 100644
--- a/modules/telco-security-lifecycle-mgmnt.adoc
+++ b/modules/security-lifecycle-mgmnt.adoc
@@ -1,11 +1,12 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="telco-security-lifecycle-mgmnt_{context}"]
+[id="security-lifecycle-mgmnt_{context}"]
 = Lifecycle management
 
 Upgrades are critical for security. When a vulnerability is discovered, it is patched in the latest z-stream release. This fix is then rolled back through each lower y-stream release until all supported versions are patched. Releases that are no longer supported do not receive patches. Therefore, it is important to upgrade {product-title} clusters regularly to stay within a supported release and ensure they remain protected against vulnerabilities.
 
 For more information about lifecycle management and upgrades, see "Upgrading a telco core CNF clusters".
+//TODO Update title
diff --git a/modules/telco-security-linux-capabilities-overview.adoc b/modules/security-linux-capabilities-overview.adoc
similarity index 76%
rename from modules/telco-security-linux-capabilities-overview.adoc
rename to modules/security-linux-capabilities-overview.adoc
index 477bdfb51f87..5805812cebe8 100644
--- a/modules/telco-security-linux-capabilities-overview.adoc
+++ b/modules/security-linux-capabilities-overview.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc
+// * edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="telco-security-linux-capabilities-overview_{context}"]
+[id="security-linux-capabilities-overview_{context}"]
 = Linux capabilities
 
 Linux capabilities define the actions a process can perform on the host system. By default, pods are granted several capabilities unless security measures are applied. These default capabilities are as follows:
@@ -27,5 +27,5 @@ You must not assign the following capabilities to a pod:
 * `SYS_ADMIN`: A powerful capability that grants elevated privileges. Allowing this capability can break security boundaries and pose a significant security risk.
 * `NET_ADMIN`: Allows control over networking, like SR-IOV ports, but can be replaced with alternative solutions in modern setups.
 
-For more information about Linux capabilities, see link:https://man7.org/linux/man-pages/man7/capabilities.7.html[Linux capabilities] man page.
+For more information about Linux capabilities, see the link:https://man7.org/linux/man-pages/man7/capabilities.7.html[Linux capabilities] man page.
 ====
\ No newline at end of file
diff --git a/modules/telco-security-pod-sec-in-kub-and-ocp.adoc b/modules/security-pod-sec-in-kub-and-ocp.adoc
similarity index 66%
rename from modules/telco-security-pod-sec-in-kub-and-ocp.adoc
rename to modules/security-pod-sec-in-kub-and-ocp.adoc
index 465999e4e421..2e876619c7c7 100644
--- a/modules/telco-security-pod-sec-in-kub-and-ocp.adoc
+++ b/modules/security-pod-sec-in-kub-and-ocp.adoc
@@ -1,11 +1,11 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="telco-security-pod-sec-in-kub-and-ocp_{context}"]
+[id="security-pod-sec-in-kub-and-ocp_{context}"]
 = Advancement of pod security in Kubernetes and {product-title}
 
 Kubernetes initially had limited pod security. When {product-title} integrated Kubernetes, Red Hat added pod security through Security Context Constraints (SCCs). In Kubernetes version 1.3, `PodSecurityPolicy` (PSP) was introduced as a similar feature. However, Pod Security Admission (PSA) was introduced in Kubernetes version 1.21, which resulted in the deprecation of PSP in Kubernetes version 1.25.
 
-PSA also became available in {product-title} version 4.11. While PSA improves pod security, it lacks some features provided by SCCs that are still necessary for telco use cases. Therefore, {product-title} continues to support both PSA and SCCs.
\ No newline at end of file
+PSA also became available in {product-title} version 4.11. While PSA improves pod security, it lacks features provided by SCCs that are still necessary for certain use cases. Therefore, {product-title} continues to support both PSA and SCCs.
\ No newline at end of file
diff --git a/modules/security-rbac-overview.adoc b/modules/security-rbac-overview.adoc
new file mode 100644
index 000000000000..6e29fdf02232
--- /dev/null
+++ b/modules/security-rbac-overview.adoc
@@ -0,0 +1,39 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="security-rbac-overview_{context}"]
+= RBAC overview
+
+Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. 
+
+Cluster administrators can use the cluster roles and bindings to control who has various access levels to the {product-title} platform itself and all projects.
+
+Developers can use local roles and bindings to control who has access to their projects. Authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.
+
+Authorization is managed using the following authorization objects:
+
+Rules:: Sets of permitted actions on specific objects. For example, a rule can determine whether a user or service account can create pods. Each rule specifies an API resource, the resource within that API, and the allowed action.
+
+Roles:: Collections of rules that define what actions users or groups can perform. You can associate or bind rules to multiple users or groups. A role file can contain one or more rules that specify the actions and resources allowed for that role. 
++
+Roles are categorized into the following types:
+
+* Cluster roles can be defined at the cluster level. They are not tied to a single namespace. They can apply across all namespaces or specific namespaces when you bind them to users, groups, or service accounts.
+* Project roles can be created within a specific namespace, and they only apply to that namespace. You can assign permissions to specific users to create roles and role bindings within their namespace, ensuring they do not affect other namespaces.
+
+Bindings:: Associations between users and/or groups with a role. You can create a role binding to connect the rules in a role to a specific user ID or group. This brings together the role and the user or group, defining what actions they can perform.
++
+[NOTE]
+====
+You can bind more than one role to a user or group.
+====
+
+For more information on RBAC, see "Using RBAC to define and apply permissions".
+
+[discrete]
+[id="security-operational-rbac-considerations_{context}"]
+== Operational RBAC considerations
+
+To reduce operational overhead, it is important to manage access through groups rather than handling individual user IDs across multiple clusters. By managing groups at an organizational level, you can streamline access control and simplify administration across your organization.
diff --git a/modules/telco-security-replacing-kubeadmin-user.adoc b/modules/security-replacing-kubeadmin-user.adoc
similarity index 89%
rename from modules/telco-security-replacing-kubeadmin-user.adoc
rename to modules/security-replacing-kubeadmin-user.adoc
index daba1341bf7c..1b0658b47fd0 100644
--- a/modules/telco-security-replacing-kubeadmin-user.adoc
+++ b/modules/security-replacing-kubeadmin-user.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
 
 :_mod-docs-content-type: PROCEDURE
-[id="telco-security-replacing-kubeadmin-user_{context}"]
+[id="security-replacing-kubeadmin-user_{context}"]
 = Replacing the kubeadmin user with a cluster-admin user
 
 The `kubeadmin` user with the `cluster-admin` privileges is created on every cluster by default. To enhance the cluster security, you can replace the`kubeadmin` user with a `cluster-admin` user and then disable or remove the `kubeadmin` user.
@@ -35,7 +35,7 @@ $ oc adm policy add-cluster-role-to-user cluster-admin <emergency_user>
 $ oc whoami
 ----
 +
-Ensure the output shows the emergency user's ID.
+Ensure the output shows the ID of the emergency user.
 
 . Store the password or authentication key for the emergency user securely in a virtual vault. 
 +
diff --git a/modules/telco-security-rhcos-overview.adoc b/modules/security-rhcos-overview.adoc
similarity index 81%
rename from modules/telco-security-rhcos-overview.adoc
rename to modules/security-rhcos-overview.adoc
index 105a2a0429a8..31acc14ec7a7 100644
--- a/modules/telco-security-rhcos-overview.adoc
+++ b/modules/security-rhcos-overview.adoc
@@ -1,14 +1,14 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-host-sec.adoc
+// * edge_computing/day_2_core_cnf_clusters/security/security-host-sec.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="telco-security-rhcos-overview_{context}"]
+[id="security-rhcos-overview_{context}"]
 = {op-system-first}
 
 {op-system-first} is different from {op-system-base-full} in key areas. For more information, see "About {op-system}".
 
-From a telco perspective, a major distinction is the control of `rpm-ostree`, which is updated through the Machine Config Operator. 
+A major distinction is the control of `rpm-ostree`, which is updated through the Machine Config Operator. 
 
 {op-system} follows the same immutable design used for pods in {product-title}. This ensures that the operating system remains consistent across the cluster. For information about {op-system} architecture, see "{op-system-first}".
 
@@ -18,11 +18,11 @@ To manage hosts effectively while maintaining security, avoid direct access when
 * Direct SSHs
 * Console access
 
-Review the following {op-system} secruity mechanisms that are integral to maintaining host security: 
+Review the following {op-system} security mechanisms that are integral to maintaining host security: 
 
 Linux namespaces:: Provide isolation for processes and resources. Each container keeps its processes and files within its own namespace. If a user escapes from the container namespace, they could gain access to the host operating system, potentially compromising security.
 
-Security-Enhanced Linux (SELinux):: Enforces mandatory access controls to restrict access to files and directories by processes. It adds an extra layer of security by preventing unauthorized access to files if a process tries to break its confinement.
+Security-Enhanced Linux (SELinux):: Enforces mandatory access controls to restrict access to files and directories by processes. SELinux adds an extra layer of security by preventing unauthorized access to files if a process tries to break its confinement.
 +
 SELinux follows the security policy of denying everything unless explicitly allowed. If a process attempts to modify or access a file without permission, SELinux denies access. For more information, see link:https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/using_selinux/index#introduction-to-selinux_getting-started-with-selinux[Introduction to SELinux].
 
diff --git a/modules/telco-security-sec-accounts-overview.adoc b/modules/security-sec-accounts-overview.adoc
similarity index 86%
rename from modules/telco-security-sec-accounts-overview.adoc
rename to modules/security-sec-accounts-overview.adoc
index 926d08d45aea..fdf1fb0d6503 100644
--- a/modules/telco-security-sec-accounts-overview.adoc
+++ b/modules/security-sec-accounts-overview.adoc
@@ -1,9 +1,9 @@
 // Module included in the following assemblies:
 //
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
+// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
 
 :_mod-docs-content-type: CONCEPT
-[id="telco-security-sec-accounts-overview_{context}"]
+[id="security-sec-accounts-overview_{context}"]
 = Security accounts overview
 
 A service account is an {product-title} account that allows a component to directly access the API. Service accounts are API objects that exist within each project.
diff --git a/modules/security-sec-considerations-telco.adoc b/modules/security-sec-considerations-telco.adoc
new file mode 100644
index 000000000000..d8c21624aba9
--- /dev/null
+++ b/modules/security-sec-considerations-telco.adoc
@@ -0,0 +1,15 @@
+// Module included in the following assemblies:
+//
+// * edge_computing/day_2_core_cnf_clusters/security/security-basics.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="security-sec-considerations-{context}"]
+= Security considerations
+
+Corporate workloads handle sensitive data and demand high reliability. A single security vulnerability can lead to broader, cluster-wide compromises. With numerous components running on an OpenShift cluster, each component must be secured to prevent any breach from escalating. Ensuring security across the entire infrastructure, including all components, is essential to maintaining the integrity of the network and avoiding vulnerabilities.
+
+The following key security features are essential for all industries that handle sensitive data:
+
+* Security Context Constraints (SCCs): Provide granular control over pod security in the OpenShift clusters.
+* Pod Security Admission (PSA): Kubernetes-native pod security controls.
+* Encryption: Ensures data confidentiality in high-throughput network environments.
\ No newline at end of file
diff --git a/modules/telco-security-infra.adoc b/modules/telco-security-infra.adoc
deleted file mode 100644
index 6a2e44a35124..000000000000
--- a/modules/telco-security-infra.adoc
+++ /dev/null
@@ -1,11 +0,0 @@
-// Module included in the following assemblies:
-//
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="telco-security-infra_{context}"]
-= Telco-specific infrastructure
-
-Hardware requirements:: In telco networks, clusters are primarily built on bare-metal hardware. This means that the operating system (op-system-first) is installed directly on the physical machines, without using virtual machines. This reduces network connectivity complexity, minimizes latency, and optimizes CPU usage for applications.
-
-Network requirements:: Telco networks require much higher bandwidth compared to standard IT networks. Telco networks commonly use dual-port 25 GB connections or 100 GB Network Interface Cards (NICs) to handle massive data throughput. Security is critical, requiring encrypted connections and secure endpoints to protect sensitive personal data.
\ No newline at end of file
diff --git a/modules/telco-security-rbac-overview.adoc b/modules/telco-security-rbac-overview.adoc
deleted file mode 100644
index e29af293376c..000000000000
--- a/modules/telco-security-rbac-overview.adoc
+++ /dev/null
@@ -1,39 +0,0 @@
-// Module included in the following assemblies:
-//
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="telco-security-rbac-overview_{context}"]
-= RBAC overview
-
-Role-based access control (RBAC) objects determine whether a user is allowed to perform a given action within a project. 
-
-Cluster administrators can use the cluster roles and bindings to control who has various access levels to the {product-title} platform itself and all projects.
-
-Developers can use local roles and bindings to control who has access to their projects. Note that authorization is a separate step from authentication, which is more about determining the identity of who is taking the action.
-
-Authorization is managed using the following authorization objects:
-
-Rules:: Are sets of permitted actions on specific objects. For example, a rule can determine whether a user or service account can create pods. Each rule specifies an API resource, the resource within that API, and the allowed action.
-
-Roles:: Are collections of rules that define what actions users or groups can perform. You can associate or bind rules to multiple users or groups. A role file can contain one or more rules that specify the actions and resources allowed for that role. 
-+
-Roles are categorized into the following types:
-
-* Cluster roles: You can define cluster roles at the cluster level. They are not tied to a single namespace. They can apply across all namespaces or specific namespaces when you bind them to users, groups, or service accounts.
-* Project roles: You can create project roles within a specific namespace, and they only apply to that namespace. You can assign permissions to specific users to create roles and role bindings within their namespace, ensuring they do not affect other namespaces.
-
-Bindings:: Are associations between users and/or groups with a role. You can create a role binding to connect the rules in a role to a specific user ID or group. This brings together the role and the user or group, defining what actions they can perform.
-+
-[NOTE]
-====
-You can bind more than one role to a user or group.
-====
-
-For more information on RBAC, see "Using RBAC to define and apply permissions".
-
-[discrete]
-[id="telco-security-operational-rbac-considerations_{context}"]
-== Operational RBAC considerations
-
-To reduce operational overhead, it is important to manage access through groups rather than handling individual user IDs across multiple clusters. By managing groups at an organizational level, you can streamline access control and simplify administration across your organization.
diff --git a/modules/telco-security-sec-considerations-telco.adoc b/modules/telco-security-sec-considerations-telco.adoc
deleted file mode 100644
index 350e4f64c858..000000000000
--- a/modules/telco-security-sec-considerations-telco.adoc
+++ /dev/null
@@ -1,15 +0,0 @@
-// Module included in the following assemblies:
-//
-// * edge_computing/day_2_core_cnf_clusters/security/telco-security-basics.adoc
-
-:_mod-docs-content-type: CONCEPT
-[id="telco-security-sec-considerations-telco_{context}"]
-= Security considerations for telco CNFs
-
-Telco workloads handle vast amounts of sensitive data and demand high reliability. A single security vulnerability can lead to broader cluster-wide compromises. With numerous components running on a {sno} cluster, each component must be secured to prevent any breach from escalating. Ensuring security across the entire infrastructure, including all components, is essential to maintaining the integrity of the telco network and avoiding vulnerabilities.
-
-The following key security features are essential for telco:
-
-* Security Context Constraints (SCCs): Provide granular control over pod security in the OpenShift clusters.
-* Pod Security Admission (PSA): Kubernetes-native pod security controls.
-* Encryption: Ensures data confidentiality in high-throughput network environments.
\ No newline at end of file