Users module provides administrative control over all users in the system. This module is only available to Administrators.
Users module makes it easy to:
Create New Users
Manage User Access to Projects, Groups and Self-Service API
Perform User Updates including Name, Email, Username, Role, Password Change, Reset 2FA, Disable 2FA
Block Sign In or Activate Sign In for users
View Login History for a user
View Audit Logs for a user
Delete a user
Where enabled on your Enterprise tenant, new users can self-register accounts from the login page. They will need to activate their account (via email activation link) before they can sign in.
The first time a user logs into AttackForge, the user will receive a QR code to scan with their mobile authenticator app to enable two-factor authentication (2FA) for their account. By default, 2FA is mandatory and enforced on all accounts. This can be disabled on a user-by-user basis by Administrators.
Administrators can create new users in the system directly, without having to go through registration workflow. This is useful when you need to create accounts fast or when you don't have access to an email address for activation.
You can create a new user in the system by clicking on
Create New User button.
When creating a new user, you can assign any user role available in the system. Newly created account are already verified and activated so they can log in immediately.
You can manage a users' access to groups by using the actions menu and selecting
Manage Access to Groups
Here you can update a users' permissions on any groups they are members of, or you can remove their access.
If you update a users' access to a group, the new privileges will apply immediately across all projects linked to the group.
If you remove a users' access to a group, this will remove the user from any of the groups' linked projects so they will no longer be able to access the projects or see any associated vulnerabilities and data.
You can also select
Grant Access to Groups in order to invite the user to multiple groups at once.
You can manage a users' access to projects by using the actions menu and selecting
Manage Access to Projects
Here you can update a users' permissions on any projects they are an existing team member, or you can remove their access.
If you update a users' access to a project, the new privileges will apply immediately on the project.
If you remove a users' access to a project, this will remove the user from the project immediately. They will no longer be able to see any of the projects' vulnerabilities and data.
You can also select
Grant Access to Projects in order to invite the user to multiple projects at once. You can individually control the level of access on each project.
You can manage a users' access to the Self-Service API (SSAPI) by using the actions menu and selecting
Manage Access to Self-Service API
Here you can update a users' permissions on any SSAPI methods/endpoints, or you can remove their access.
!IMPORTANT: By default, all users have no access to the SSAPI. Access is granted explicitly by the Administrators to a user from within the Users module. Access to the SSAPI is controlled & applied on an individual method/endpoint level.
Every user in the system can generate or rotate their API key by visiting Self-Service API module and clicking on
Generate New Key button.
The My API section will show the user which API methods/endpoints they have access to.
In order for a user to use the SSAPI:
Administrator must first grant the user with access to the required method/endpoint
User can generate their own API Key to authenticate their API requests
User can access the API documentation and sample cURL requests to get started quickly
If you would like to create a service account in the system with non-interactive access to the application interface - you can grant the user permissions via the SSAPI, then block the user so they cannot login to the application. They will still be able to access the SSAPI.
Reports can be customized by users within the application. This allows users to create content within the reports which is relevant to the reader, or purpose.
For example, if the report needs to go to an Executive - they may not have the time to read through hundreds of pages of technical analysis. You can create a report that is structured to provide only the information the Executive cares about.
Another example is when reports need to be provided to 3rd parties or auditors. Considering vulnerability reports contain sensitive data on how to exploit issues, this information may need to be redacted before it is sent to the party. You can create a report that will omit any screenshots, steps to reproduce findings, etc. which may be deemed too sensitive to share with external parties.
As an Administrator, you can override a users' report settings by clicking on
Customize Vulnerability Reports from the actions menu.
As an Administrator, you can update the following user details for another user:
These actions can be performed using the the actions menu.
AttackForge is built on Roles-Based-Access-Controls (RBAC) at two different levels:
Application User Roles – determines what modules the user has access to, and functionality within those modules.
Project Roles – determines what privileges & functions a user has access to on a project; and the data they will have access to in AttackForge across all modules.
There are currently five (5) application user roles:
Client (standard user)
Consultant (standard user)
Standard users can do the following:
Access Global Dashboard;
Access Analytics module;
Access Projects module (can only see any projects they have been invited to; or project requests they have made);
Access Retesting module;
Access Schedule module (can only see projects; cannot filter by users);
Access Reporting module (can only download reports);
Access Search module;
Access Self-Service API (by default has no access to API methods/endpoints);
Access Attack Chains module;
Access Themes module;
Access Help & Support
As an Administrator, you can update a users' role in the system to any of the following:
Client - standard user
Consultant - standard user
Library Moderator - standard user +
full access to the Vulnerability Library module
Project Coordinator - standard user +
can create new projects
can update projects
gets access to all new projects (optional)
can invite users to projects
can manage user access to projects
can access all pending & actioned project requests
can approve new project requests
can request more information on project requests
can reject new project requests
assign assets to test cases on a project
lock test cases on a project
unlock test cases on a project
download ReportGen Baseline template
upload new ReportGen templates
modify existing ReportGen templates
full access to the Vulnerability Library module
full access to the Test Suite Builder module
Administrator - super user
As an Administrator, you can reset a users' 2FA enrolment so that they will receive a new QR code to scan upon next login. This is useful if the user has lost access to the mobile device with the previous code.
You can also disable a users' requirement to 2FA. By default, all users in AttackForge have 2FA enabled. However you can override this and disable on an individual user basis.
As an Administrator, you can block a user from being able to sign in to the application. Note this does not affect the Service API. You can also reactivate a users' ability to sign in when required.
This functionality is useful if a user has left their organisation and they no longer require access to AttackForge.
You can view a users' log in history which details and timestamps for every login attempt by the user.
You can view audit logs collected by AttackForge regarding events relating to the user. This includes detailed information that can be integrated with log management tools.
You can delete a user from AttackForge. When a user is deleted, any data they have created in AttackForge will remain - for integrity & auditing purposes.