diff --git a/alpha/engagements/2024/Eclipse Foundation/update-2024-09.md b/alpha/engagements/2024/Eclipse Foundation/update-2024-09.md
new file mode 100644
index 00000000..32d7eaed
--- /dev/null
+++ b/alpha/engagements/2024/Eclipse Foundation/update-2024-09.md	
@@ -0,0 +1,41 @@
+# Eclipse Foundation Update — September 2024
+
+## Identity and Access Management
+
+We have completed our investigation into replacing our current identity provider with our in-house Keycloak setup. The investigation focused primarily on replicating the look and feel of the current login page and integrating a 2FA workflow. We designed a process for users to set up 2FA and for enforcing 2FA for all committers.
+
+Additionally, we have begun investigating how to migrate TOTP-based 2FA from GitLab’s internal datastore at [gitlab.eclipse.org](https://gitlab.eclipse.org) to Keycloak. This is to avoid disabling 2FA for many users who already have it enabled and then requiring them to re-enable it in the new Keycloak-based system. Our goal is to make this process as seamless as possible to facilitate a smooth transition and minimize friction for our users.
+
+We have also completed migrating all our authenticated APIs to use our Keycloak-based identity provider for authentication. This migration enhances security and provides a unified authentication experience across our services.
+
+## Update on Security Policy
+
+We have finalized an update to the [Eclipse Foundation Security Policy](https://www.eclipse.org/security/policy/), which has been approved by the Eclipse Foundation Architecture Council. This update can now be presented to the board for validation. The [changes](https://gitlab.eclipse.org/eclipsefdn/emo-team/policies/security-policy/-/commit/25f816a4809e1043256bacf9fff15e294b7eb43f) primarily revolve around the introduction of Project Security Teams—a concept introduced earlier this summer.
+
+Project Security Teams are dedicated groups within each project responsible for handling security vulnerabilities and coordinating responses. Their introduction aims to improve our overall security posture by ensuring that security issues are addressed promptly and effectively at the project level.
+
+## Communication
+
+We have published a FAQ document in the [form of a blog post](https://blogs.eclipse.org/post/marta-rybczynska/project-security-teams-faq) regarding the Project Security Teams. This resource aims to provide clarity and answer common questions about the new security initiative.
+
+Additionally, we held a [webinar](https://www.youtube.com/watch?v=7Z3WQJMQGIo) explaining the rules that a CNA, like the Eclipse Foundation, must follow. This was prompted by the fact that, as of August 2024, a [new set of rules](https://www.cve.org/Resources/Roles/Cnas/CNA_Rules_v4.0.pdf) for CNAs has come into effect. The webinar aimed to inform our community about these changes and how they impact our vulnerability reporting processes.
+
+Finally, we Presented Eclipse OtterDog at the [Open Source Summit in Vienna](https://osseu2024.sched.com/event/1ej3f/policing-open-source-projects-at-scale-thomas-neidhart-eclipse-foundation).
+
+## Vulnerability Management
+
+The NIST's NVD has conducted an [audit](https://nvd.nist.gov/vuln/cvmap/report/16610) of the Eclipse Foundation's CVE submissions. The audit assessed the number of matching CWEs between what we reported and what NIST considered to be the correct CWEs.
+
+Our acceptance level has risen to Contributor status, meaning that over 70% of the reported CWEs were deemed accurate over the past five years. This is a significant improvement and reflects our ongoing commitment to accurate vulnerability reporting. The report also shows a steady increase in accuracy since the beginning of the Alpha-Omega sponsorship.
+
+## Public Policy
+
+The following organizations have completed the necessary paperwork to join the [Open Regulatory Compliance Working Group](https://orcwg.org) over the past month:
+
+- Siemens AG
+- Lunatech B.V.
+- Open Source Initiative
+- Mercedes-Benz Tech Innovation GmbH
+- Software Heritage
+
+The Open Regulatory Compliance Working Group aims to help organizations navigate regulatory requirements related to open source software. By joining, these organizations are contributing to the development of tools and best practices for regulatory compliance in open source projects.