<!-- This issue template can be used as a great starting point for feature requests. Learn more about the process: https://handbook.gitlab.com/handbook/product/product-management/#customer-feature-requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md). --> ### Release notes <!-- What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). " --> ### Summary GitLab.com should support organization or top-level-group audit visibility for SSH key changes made by users who have access to that organization, even when those users are not enterprise users. ### Problem to solve Today, SSH key audit coverage is not sufficient for customers who: - use GitLab.com - rely on SAML or group membership for organization access - intentionally allow users to retain standard community GitLab identities - need organization-level auditability for compliance and incident response For example, users are not always enterprise-managed users, but those users can still authenticate into and operate within the organization. If one of those users adds or removes an SSH key from their GitLab.com account, the organization cannot reliably observe that change at the organization level. This creates a compliance gap for customers who need a clear audit trail of credential changes for users who can access their organization. ### Existing behavior GitLab has `add_ssh_key` and `remove_ssh_key` audit events, but the group-scoped visibility is tied to enterprise users. That means the current implementation does not satisfy customers whose organization access model depends on standard GitLab accounts plus SAML or group access, rather than enterprise-user ownership. ### Proposal Provide one of the following: 1. **Preferred** Allow `add_ssh_key` and `remove_ssh_key` to surface at the top-level group or organization scope for users who are currently authorized in that organization, even if they are not enterprise users. 2. **Acceptable alternative** Emit an organization-relevant audit event during Git-over-SSH activity that includes the public key identifier used, so customers can detect that a user has changed keys even if the add/remove event itself cannot be directly tied to org membership at that exact moment. **Suggested event details** If implemented, the event should ideally include: - user ID / username - top-level group or organization context - key ID and, if possible, fingerprint or title - timestamp - source IP - whether the action was add or remove - enough metadata to correlate with subsequent Git-over-SSH usage ### Why this matters Customers with regulated environments need to answer questions like: - When did this user change SSH credentials? - Was this user able to access our organization at that time? - Which credential was later used for Git activity? - Can we reconstruct a reliable audit trail during a security investigation? Without this capability, customers must rely on partial workarounds that are difficult to operationalize and may still fail audit expectations. ### Intended users <!-- Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas are described at https://handbook.gitlab.com/handbook/product/personas/ * [Parker (Product Manager)](https://handbook.gitlab.com/handbook/product/personas/#parker-product-manager) * [Delaney (Development Team Lead)](https://handbook.gitlab.com/handbook/product/personas/#delaney-development-team-lead) * [Presley (Product Designer)](https://handbook.gitlab.com/handbook/product/personas/#presley-product-designer) * [Sasha (Software Developer)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer) * [Priyanka (Platform Engineer)](https://handbook.gitlab.com/handbook/product/personas/#priyanka-platform-engineer) * [Sidney (Systems Administrator)](https://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) * [Rachel (Release Manager)](https://handbook.gitlab.com/handbook/product/personas/#rachel-release-manager) * [Simone (Software Engineer in Test)](https://handbook.gitlab.com/handbook/product/personas/#simone-software-engineer-in-test) * [Allison (Application Ops)](https://handbook.gitlab.com/handbook/product/personas/#allison-application-ops) * [Ingrid (Infrastructure Operator)](https://handbook.gitlab.com/handbook/product/personas/#ingrid-infrastructure-operator) * [Dakota (Application Development Director)](https://handbook.gitlab.com/handbook/product/personas/#dakota-application-development-director) * [Dana (Data Analyst)](https://handbook.gitlab.com/handbook/product/personas/#dana-data-analyst) * [Eddie (Content Editor)](https://handbook.gitlab.com/handbook/product/personas/#eddie-content-editor) * [Amy (Application Security Engineer)](https://handbook.gitlab.com/handbook/product/personas/#amy-application-security-engineer) * [Isaac (Infrastructure Engineer)](https://handbook.gitlab.com/handbook/product/personas/#isaac-infrastructure-security-engineer) * [Alex (Security Operations Engineer)](https://handbook.gitlab.com/handbook/product/personas/#alex-security-operations-engineer) * [Cameron (Compliance Manager)](https://handbook.gitlab.com/handbook/product/personas/#cameron-compliance-manager) --> ### Feature Usage Metrics <!-- How are you going to track usage of this feature? Think about user behavior and their interaction with the product. What indicates someone is getting value from it? Explore (../../doc/development/internal_analytics/internal_event_instrumentation/quick_start.md) for a guide. --> ### Does this feature require an audit event? <!--- Check out these docs to know more https://docs.gitlab.com/development/audit_event_guide/#what-are-audit-events https://docs.gitlab.com/administration/compliance/audit_event_reports/ ---> <!-- Label reminders Make sure to add the appropriate labels for the product stage and/or group (e.g ~"devops::plan") if known and add a comment tagging the appropriate Product Manager. Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/ Examples: /label ~group:: ~section:: ~Category: /label ~"GitLab Free" ~"GitLab Premium" ~"GitLab Ultimate" -->