diff --git a/README.md b/README.md
index 368aa88a46..ac9aae1476 100644
--- a/README.md
+++ b/README.md
@@ -1,88 +1,27 @@
-# Welcome to the OWASP Cheat Sheet Series
+# OWASP Cheat Sheet Series
 
-[![OWASP Flagship](https://img.shields.io/badge/owasp-flagship%20project-48A646.svg)](https://www.owasp.org/index.php/OWASP_Project_Inventory#tab=Flagship_Projects)
-[![Creative Commons License](https://img.shields.io/github/license/OWASP/CheatSheetSeries)](https://creativecommons.org/licenses/by-sa/4.0/ "CC BY-SA 4.0")
+The OWASP Cheat Sheet Series project provides high-value information on specific application security topics.
 
-Welcome to the official repository for the Open Worldwide Application Security Project® (OWASP) Cheat Sheet Series project. The project focuses on providing good security practices for builders in order to secure their applications.
+## Authors
 
-In order to read the cheat sheets and **reference** them, use the project [official website](https://cheatsheetseries.owasp.org). The project details can be viewed on the [OWASP main website](https://owasp.org/www-project-cheat-sheets/) without the cheat sheets.
-
-:triangular_flag_on_post: Markdown files are the working sources and aren't intended to be referenced in any external documentation, books or websites.
-
-## Cheat Sheet Series Team
-
-### Project Leaders
-
-- [Jim Manico](https://github.com/jmanico)
-- [Jakub Maćkowski](https://github.com/mackowski)
-- [Shlomo Zalman Heigh](https://github.com/szh)
-
-### Core team
-
-- [Kevin W. Wall](https://github.com/kwwall)
+- Jim Manico  
+- Tanya Janca  
+- Andrew van der Stock  
 
 ## Chat With Us
 
-We're easy to find on Slack:
-
-1. Join the OWASP Group Slack with this [invitation link](https://owasp.org/slack/invite).
-2. Join the [#cheatsheets channel](https://owasp.slack.com/messages/C073YNUQG).
-
-Feel free to ask questions, suggest ideas, or share your best recipes.
-
-## Contributions, Feature Requests, and Feedback
-
-We are actively inviting new contributors! To start, please read the [contribution guide](CONTRIBUTING.md).
-
-This project is only possible thanks to the work of many dedicated volunteers. Everyone is encouraged to help in ways large and small. Here are a few ways you can help:
-
-- Read the current content and help us fix any spelling mistakes or grammatical errors.
-- Choose an existing [issue](https://github.com/OWASP/CheatSheetSeries/issues) on GitHub and submit a pull request to fix it.
-- Open a new issue to report an opportunity for improvement.
-
-### Automated Build
-
-This [link](https://cheatsheetseries.owasp.org/bundle.zip) allows you to download a build (ZIP archive) of the offline website.
-
-### Local Build [![pyVersion3x](https://img.shields.io/badge/python-3.x-blue.svg)](https://www.python.org/downloads/)
-
-The OWASP Cheat Sheet Series website can be built and tested locally by issuing the following commands:
-
-```sh
-make install-python-requirements
-make generate-site
-make serve  # Binds port 8000
-```
-
-### Container Build
-
-The OWASP Cheat Sheet Series website can be built and tested locally inside a container by issuing the following commands:
-
-#### Docker
-
-```sh
-docker build -t cheatsheetseries .
-docker run --name cheatsheetseries -p 8000:8000 cheatsheetseries
-```
-
-#### Podman
-
-```sh
-podman build -t cheatsheetseries .
-podman run --name cheatsheetseries -p 8000:8000 localhost/cheatsheetseries
-```
+Join us on our [Slack](https://owasp.org/slack)
 
-## Contributors
+## Conversion Rules
 
-- **From 2014 to 2018:** [V1](CONTRIBUTOR-V1.md) - Initial version of the project hosted on the [OWASP WIKI](https://wiki.owasp.org).
-- **From 2019:** [V2](https://github.com/OWASP/CheatSheetSeries/graphs/contributors) - Hosted on [GitHub](https://github.com/OWASP/CheatSheetSeries).
+- Use Markdown (.md) files for cheatsheets.  
+- Follow consistent heading levels.  
+- Keep lines under 120 characters.  
 
-## Special thanks
+## Editor
 
-A special thank you to the following people for their help provided during the migration:
+We use Visual Studio Code with markdownlint plugin for linting.
 
-- [Dominique Righetto](https://github.com/righettod): For his special leadership and guidance.
-- [Elie Saad](https://github.com/ThunderSon): For valuable help in updating the OWASP Wiki links for all the migrated cheat sheets and for years of leadership and other project support.
-- [Jakub Maćkowski](https://github.com/mackowski): For valuable help in updating the OWASP Wiki links for all the migrated cheat sheets.
+## Status
 
-Open Worldwide Application Security Project and OWASP are registered trademarks of the OWASP Foundation, Inc.
+All cheatsheets are continuously improved and reviewed.
diff --git a/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.md b/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.md
index 9e2d9ab409..a72fa4dce4 100644
--- a/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.md
+++ b/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.md
@@ -55,6 +55,12 @@ This XML structure has three main sections (or nodes):
       The tests will use this as a input source for the different test cases by:
       1) Defining legitimate access and the correct implementation
       2) Identifying illegitimate access (authorization definition issue
+      This file materialize the authorization matrix for the different 
+      services exposed by the system.
+
+      It will be used by the tests as a input sources for the different tests cases:
+      1) Evaluate legitimate access and is correct implementation
+      2) Identify not legitimate access (authorization definition issue 
       on service implementation)
 
       The "name" attribute is used to uniquely identify a SERVICE or a ROLE.
@@ -62,6 +68,7 @@ This XML structure has three main sections (or nodes):
   <authorization-matrix>
 
       <!-- Describe the possible logical roles used in the system, is used here to
+      <!-- Describe the possible logical roles used in the system, is used here to 
       provide a list+explanation
       of the different roles (authorization level) -->
       <roles>
@@ -74,6 +81,7 @@ This XML structure has three main sections (or nodes):
       </roles>
 
       <!-- List and describe the available services exposed by the system and the associated
+      <!-- List and describe the available services exposed by the system and the associated 
       logical role(s) that can call them -->
       <services>
           <service name="ReadSingleMessage" uri="/{messageId}" http-method="GET"
@@ -387,6 +395,22 @@ Time elapsed: 0.05 s  ### FAILURE!
 java.lang.AssertionError:
 Access issues detected using the BASIC USER point of view:
     The service 'DeleteMessage' when called with POV 'BASIC' return
+```
+testAccessUsingAnonymousUserPointOfView(org.owasp.pocauthztesting.AuthorizationMatrixIT)  
+Time elapsed: 1.009 s  ### FAILURE
+java.lang.AssertionError:
+Access issues detected using the ANONYMOUS USER point of view:
+    The service 'DeleteMessage' when called with POV 'ANONYMOUS' return 
+    a response code 200 that is not the expected one (403 expected).
+    
+    The service 'CreateMessage' when called with POV 'ANONYMOUS' return 
+    a response code 200 that is not the expected one (403 expected).
+
+testAccessUsingBasicUserPointOfView(org.owasp.pocauthztesting.AuthorizationMatrixIT)  
+Time elapsed: 0.05 s  ### FAILURE!
+java.lang.AssertionError:
+Access issues detected using the BASIC USER point of view:
+    The service 'DeleteMessage' when called with POV 'BASIC' return 
     a response code 200 that is not the expected one (403 expected).
 ```
 
diff --git a/cheatsheets/CISA_Secure_By_Design_Cheat_Sheet.md b/cheatsheets/CISA_Secure_By_Design_Cheat_Sheet.md
new file mode 100644
index 0000000000..f9c0744c1b
--- /dev/null
+++ b/cheatsheets/CISA_Secure_By_Design_Cheat_Sheet.md
@@ -0,0 +1,23 @@
+# CISA Secure By Design Cheat Sheet
+
+## Core Principles
+
+- Treat security as a core process, not a feature.  
+- Conduct threat modeling during design.  
+- Make security decisions visible and documented.  
+
+## Leadership and Accountability
+
+- Executive and engineering leaders must ensure secure-by-design principles.  
+- Include security goals in performance reviews.  
+
+## Technical Practices
+
+- Systems should be secure without depending on additional components.  
+- Disable unnecessary features and interfaces.  
+- Security should be integrated throughout the SDLC.  
+- Apply security patterns (e.g., defense-in-depth).  
+- Avoid memory corruption vulnerabilities.  
+- Prefer high-level languages for safer defaults.  
+- Embed security awareness and continuous improvement.  
+- Provide continuous security testing and feedback.  
diff --git a/cheatsheets/Secure_Product_Design_Cheat_Sheet.md b/cheatsheets/Secure_Product_Design_Cheat_Sheet.md
index 5ca4f423a7..2c69b65906 100644
--- a/cheatsheets/Secure_Product_Design_Cheat_Sheet.md
+++ b/cheatsheets/Secure_Product_Design_Cheat_Sheet.md
@@ -6,7 +6,8 @@ The purpose of Secure Product Design is to ensure that all products meet or exce
 
 ## Methodology
 
-As a basic start, establish secure defaults, minimise the attack surface area, and fail securely to those well-defined and understood defaults.
+As a basic start, establish secure defaults, minimise the attack surface area, and fail securely to those well-defined and understood defaults.  
+**CISA Secure by Design:** Ensure memory safety, secure defaults, and a strong security-focused developer culture throughout the product lifecycle.
 
 Secure Product Design comes about through two processes:
 
@@ -23,18 +24,26 @@ Least Privilege is a security principle that states that users should only be gi
 
 Separation of duties is a fundamental principle of internal control in business and organizations. It is a system of checks and balances that ensures that no single individual has control over all aspects of a transaction. This is done by assigning different tasks to different people, so that no one person has control over the entire process. This helps to reduce the risk of fraud and errors, as well as ensuring that all tasks are completed in a timely manner. Separation of duties is an important part of any organization's internal control system, and is essential for maintaining the integrity of the organization's financial records.
 
+**CISA Secure by Design:** Implement least privilege and role separation at every layer of the system architecture.
+
 ### 2. The principle of Defense-in-Depth
 
 The principle of Defense-in-Depth is a security strategy that involves multiple layers of security controls to protect an organization’s assets. It is based on the idea that if one layer of security fails, the other layers will still be able to protect the asset. The layers of security can include physical security, network security, application security, and data security. The goal of Defense-in-Depth is to create a secure environment that is resilient to attack and can quickly detect and respond to any security incidents. By implementing multiple layers of security, organizations can reduce the risk of a successful attack and minimize the damage caused by any successful attack.
 
+**CISA Secure by Design:** Use layered protections to maintain memory safety and mitigate systemic risks.
+
 ### 3. The principle of Zero Trust
 
 Zero Trust is a security model that assumes that all users, devices, and networks are untrusted and must be verified before access is granted. It is based on the idea that organizations should not trust any user, device, or network, even if they are inside the organization’s network. Instead, all requests for access must be authenticated and authorized before access is granted. Zero Trust also requires organizations to continuously monitor and audit user activity to ensure that access is only granted to those who need it. This model is designed to reduce the risk of data breaches and other security incidents by ensuring that only authorized users have access to sensitive data.
 
+**CISA Secure by Design:** Assume no component or user is trusted by default; verify and authenticate continuously.
+
 ### 4. The principle of Security-in-the-Open
 
 Security-in-the-Open is a concept that emphasizes the importance of security in open source software development. It focuses on the need for developers to be aware of the security implications of their code and to take steps to ensure that their code is secure. This includes using secure coding practices, testing for vulnerabilities, and using secure development tools. Security-in-the-Open also encourages developers to collaborate with security experts to ensure that their code is secure.
 
+**CISA Secure by Design:** Foster a security-aware developer culture and integrate secure coding practices into the CI/CD pipeline.
+
 ## Security Focus Areas
 
 ### 1. Context
@@ -63,16 +72,17 @@ Code is the ultimate expression of the intention for a product and as such it mu
 
 Some basics of secure coding include:
 
-   1. Input validation: Verify that all input data is valid and of the expected type, format, and length before processing it. This can help prevent attacks such as SQL injection and buffer overflows.
-   2. Error handling: Handle errors and exceptions in a secure manner, such as by logging them in a secure way and not disclosing sensitive information to an attacker.
-   3. Authentication and Authorization: Implement strong authentication and authorization mechanisms to ensure that only authorized users can access sensitive data and resources.
-   4. Cryptography: Use cryptographic functions and protocols to protect data in transit and at rest, such as HTTPS and encryption - the expected levels for a given Product Security Level can often be found by reviewing your Golden Path / Paved Road documentation.
-   5. Least privilege: Use the principle of the least privilege when writing code, such that the code and the system it runs on are given the minimum access rights necessary to perform their functions.
-   6. Secure memory management: Use high-level languages recommended in your Golden Path / Paved Road documentation or properly manage memory to prevent memory-related vulnerabilities such as buffer overflows and use-after-free.
-   7. Avoiding hardcoded secrets: Hardcoded secrets such as passwords and encryption keys should be avoided in the code and should be stored in a secure storage.
-   8. Security testing: Test the software for security vulnerabilities during development and just prior to deployment.
-   9. Auditing and reviewing the code: Regularly audit and review the code for security vulnerabilities, such as by using automated tools or having a third party review the code.
-   10. Keeping up-to-date: Keep the code up-to-date with the latest security best practices and vulnerability fixes to ensure that the software is as secure as possible.
+1. Input validation: Verify that all input data is valid and of the expected type, format, and length before processing it. This can help prevent attacks such as SQL injection and buffer overflows.
+2. Error handling: Handle errors and exceptions in a secure manner, such as by logging them in a secure way and not disclosing sensitive information to an attacker.
+3. Authentication and Authorization: Implement strong authentication and authorization mechanisms to ensure that only authorized users can access sensitive data and resources.
+4. Cryptography: Use cryptographic functions and protocols to protect data in transit and at rest, such as HTTPS and encryption - the expected levels for a given Product Security Level can often be found by reviewing your Golden Path / Paved Road documentation.
+5. Least privilege: Use the principle of the least privilege when writing code, such that the code and the system it runs on are given the minimum access rights necessary to perform their functions.
+6. Secure memory management: Use high-level languages recommended in your Golden Path / Paved Road documentation or properly manage memory to prevent memory-related vulnerabilities such as buffer overflows and use-after-free.  
+**CISA Secure by Design:** Prioritize memory safety as a core architectural principle.
+7. Avoiding hardcoded secrets: Hardcoded secrets such as passwords and encryption keys should be avoided in the code and should be stored in a secure storage.
+8. Security testing: Test the software for security vulnerabilities during development and just prior to deployment.
+9. Auditing and reviewing the code: Regularly audit and review the code for security vulnerabilities, such as by using automated tools or having a third party review the code.
+10. Keeping up-to-date: Keep the code up-to-date with the latest security best practices and vulnerability fixes to ensure that the software is as secure as possible.
 
 Ensure that you integrate plausibility checks at each tier of your application (e.g., from frontend to backend) and ensure that you write unit and integration tests to validate that all threats discovered during [Threat Modeling](Threat_Modeling_Cheat_Sheet.md) have been mitigated to a level of risk acceptable to the organization. Use that to compile use-cases and [abuse-cases](Abuse_Case_Cheat_Sheet.md) for each tier of your application.
 
@@ -82,7 +92,8 @@ Building an application securely can all too easily be undone if it's not secure
 
 1. Bearing in mind the principle of Least Privilege: Limit the access and permissions of system components and users to the minimum required to perform their tasks.
 2. Remembering Defense-in-Depth: Implement multiple layers of security controls to protect against a wide range of threats.
-3. Ensuring Secure by Default: Configure systems and software to be secure by default, with minimal manual setup or configuration required.
+3. Ensuring Secure by Default: Configure systems and software to be secure by default, with minimal manual setup or configuration required.  
+**CISA Secure by Design:** Follow CISA guidelines for secure defaults across all components.
 4. Secure Data: Protect sensitive data, such as personal information and financial data, by encrypting it in transit and at rest. Protecting that data also means ensuring it's correctly backed up and that the data retention is set correctly for the desired Product Security Level.
 5. Plan to have the configuration Fail Securely: Design systems to fail in a secure state, rather than exposing vulnerabilities when they malfunction.
 6. Always use Secure Communications: Use secure protocols for communication, such as HTTPS, to protect against eavesdropping and tampering.