Account Management

Manage your organization's account, team members, and platform settings.

User Account

Access the following settings by clicking on your name and email in the top right corner.

User Profile

Your User Profile is where you manage your personal account information, security settings, and notification preferences. To access your User Profile, click your account name in the top right corner and select User Profile. [1]

User Account [1]

Update your name and email address. Your name is used for attribution when commenting on findings.

Phone Numbers [2]

Add a primary number to your profile. Phone numbers are used for contact purposes by your Sprocket team.

Two-Factor Authentication [3]

Two-factor authentication (2FA) is required for all users during creating an account. If you need to reset your 2FA method, click Reset and follow the prompts. Use Generate new recovery codes to create backup codes in case you lose access to your authenticator app.

API Credentials [4]

This is where you can generate API Credentials to utilize the Sprocket Platform Public API, more details on accessing the API can be found here: Findings Management - Sprocket Platform Public API and details on configuring and managing organization credentials can be found here: API Credentials

Notification Preferences

Notification preferences control when and how you are notified about findings activity. Notifications are sent to users assigned as a Point of Contact on a project. If you are not assigned as a POC on a project, you will not receive notifications for that project regardless of your preferences. Reach out to the user in your organization that has the Manager role if you need to be assigned to additional Projects.

The default for all notification types is Immediately. A newly assigned POC will begin receiving notifications without any additional setup.

Finding Notifications

Testing Notifications

Reset Password

To update your password, click Change Password. An authentication code will be required to complete the change.

Company Profile

The Company Profile page is shared across your organization. Any changes made by a Client Manager apply to all users. To access Company Profile, click your account name in the top right corner and select Company Profile..

Account Information and Company Address [1] [2]

Update your organization's primary contact email, phone number and company address.

Service-Level Agreement [3]

SLA settings define how long findings may remain open before a violation is triggered. SLA thresholds can be configured at the organization level here, or per project. Project-level settings supersede organization-level defaults. All users are notified when a finding has violated your SLA policy.

Organization-level SLA can only be configured by a Client Manager. Changes apply organization-wide. If multiple Client Managers update SLA settings, the most recent change takes effect.'

You can disable the SLA feature entirely for all projects by selecting Disable Service-Level Agreement feature for all projects.

Project-Level SLA

SLA can also be configured per project from the project's Engagement Details page. Both Client Managers and Client Users can configure project-level SLA. Project-level settings override the organization defaults for findings in that project. If multiple users update project SLA settings, the most recent change takes effect.

AI Integration [4]

AI Integration is on by default. Users can generate AI-powered remediation suggestions directly from published findings. This is an organization-level setting: if a Client Manager turns it off, it is off for all users in the organization.

Team Members

The Team Members page allows Client Managers to view and manage all users that have access to your organization's account. To access Team Members, click your account avatar in the top right corner and select Team.

Each team member record displays:

• User Name: The team member's name
• Permission Level: The user's role: Manager or standard user
• Project Point of Contact: The projects the user is assigned to as a point of contact, and will get notifications for
• Email Address: The user's email address
• Added On: The date the user was added to the account
• Last Login: The date the user last logged in
• Auth Method: The authentication method used, Password or SSO
• Status: The user's current access status, Active, Pending Invite, or Disabled

Roles & Permissions

Client Manager
Has full access to the platform including the ability to add and manage users, assign points of contact to projects, configure integrations, manage SLA settings, configure AI features, and trigger Stop Testing.

Client User
Has access to view and interact with findings, attack narratives, reporting, and attack surface data. Cannot manage users, configure integrations, or access organization-level settings.

A full breakdown of role-level permissions is shown below:

Inviting a User

Only Client Managers can invite new users. Invited users receive an email with instructions to access the platform, this invite will expire after 24 hours. Email domains must be pre-approved by Sprocket, if you try to add a user with an un-approved email domain, it will need to be manually verified.

To invite a user:

1. Navigate to Team Members from your account menu.
2. Click Add User in the top right corner.
3. Enter the user's first name, last name, and email address.
4. Set the Permission Level. Toggle on Manager to grant Client Manager access.
5. Assign the user as a Point of Contact for relevant projects.
6. Click Add. The user will receive an email invite.

Managing Users

Client Managers can edit settings related to individual users or remove users at any time.

To edit a user:

1. Locate the user in the Team Members list.
2. Click the edit icon.
3. Update the user's details as needed.
4. Save your changes.

To remove a user:

1. Locate the user in the Team Members list.
2. Click the delete icon.
3. Confirm the removal. The user's access will be disabled immediately.

API Credentials

API credentials let you access Sprocket data programmatically. Each credential is a pair: a Client ID and a Secret. You use them together to authenticate your API requests.

Your API credentials are personal to you and carry your level of access. Keep them secure and do not share them.

Generating an API Credential

You generate and manage your own API credential from your user profile.

1. Navigate to Account [1] > API Credentials [2].
   
2. Click Generate API Credential. [1]
   
3. A window displays your Client ID and Secret. Copy both and store them somewhere secure before you close the window. [2]

Use your Client ID and Secret together to authenticate your API requests. For request formats and available endpoints, see Findings Management - Sprocket Platform Public API

Viewing your credential

After you generate a credential, the API Credentials section updates to show you the following information:

• Credential Name: The name of your credential.
• Created: The date the credential was generated.
• Last Used: The date the credential was last used to authenticate, or Never if it has not been used yet.

A Credential History list below shows events for your credential, such as when it was generated, along with the date of each event.

Your Secret is not shown here. It is only visible once, at the moment you generate or rotate the credential.

Rotating your credential

Rotate your credential if your Secret is lost or you believe it has been exposed. Rotating replaces your existing credential with a new Client ID and Secret. The previous credential stops working once rotation is complete, so update anything using the old credential.

1. Navigate to Account > API Credentials.
2. Click Rotate Credentials.
3. A window displays your new Client ID and Secret. Copy both and store them somewhere secure before you close the window, just as you did when you first generated the credential.

Managing organization credentials

Client Managers can view and manage API credentials across the organization. This gives you oversight of who has programmatic access to your Sprocket data.

To manage organization credentials, navigate to Account [1] > API Credentials [2].

Under the Personal Credentials section, there’s a section called Organization Credentials.

Org Credentials

The Org Credentials tab lists the active credentials across your organization. Each row shows:

• Credential Name: The name of the credential, which identifies the user it belongs to.
• Created: The date the credential was generated.
• Last Used: The date the credential was last used to authenticate, or Never if it has not been used.

To revoke a credential, click Revoke Credential on that row.

Revoking a credential

Revoking a credential ends the programmatic access it provides. Revoke a credential when a user no longer needs API access, or when a credential may have been exposed. Access is lost immediately after revocation.

Audit Log

The Audit Log tab records credential activity across your organization, giving you a history of when access was granted and removed. Each entry shows:

• Event: The type of event, such as Generated or Revoked.
• Event Date: The date the event occurred.
• Credential Name: The credential the event applies to.

Single Sign-On

Single Sign-On (SSO) allows your organization to authenticate platform users through your existing identity provider. Sprocket supports SAML-based SSO including Okta and Entra.

Once SSO is configured, users authenticating via SSO will show SSO as their Auth Method on the Team Members page.

SSO configuration requires a collaborative set-up between your organization and Sprocket. To request SSO configuration, contact your Sprocket Support by emailing support@sprocketsecurity.com with the name of the provider you will be using, before following the set-up instructions below.

Project Management

Your projects are the organizing structure for testing. Each project has its own page showing the details, scope, and results for that engagement. This section explains what a project page shows and what is unique to each project type.

Project pages are a reference. All users can view them. Projects are activated by Sprocket, so you do not create or activate projects yourself.

What a project page shows

Each project page brings together the high-level information for that engagement:

• Scope. The assets included in and excluded from testing for this project, shown under the Scope tab.
• Points of contact. The people associated with this project that will get notified about Findings. See [LINK — Account Management: Points of Contact].
• Findings. A linked count of open and closed findings for this project.
• SLA. The service level agreement thresholds that apply to this project. Project-level SLAs override your organization defaults. See

The Scope tab

The Scope tab shows what is included in and excluded from testing for the project. Scope is defined by domains, IP ranges, and URLs, each set to be included in or excluded from testing.

For External Pentest and Web Application projects, the Scope tab also lists the Sprocket IPs used for testing. These are the addresses your testing traffic originates from. The list changes infrequently. Share it with your internal teams so they can recognize Sprocket testing activity and avoid blocking it.

What is unique to each project type

Most of a project page works the same way across project types. A few actions are specific to one type, and each is completed during onboarding.

External Pentest

Validate your scope report to confirm the assets included in testing are correct.

Internal Pentest

Configure your dropboxes so Sprocket can test your internal environment. For the steps, see Dropbox Deployment

Web Application

Tag your web application assets to differentiate them. Tags are how individual web applications are distinguished, and tagging is required to generate a report scoped to a specific web application. For the steps, see Attack Surface - Custom Tags.

Dropbox Deployment

Sprocket conducts the internal portion of your engagement from a hardened Ubuntu 24.04 LTS virtual appliance deployed inside your network. Before your kickoff call, your team needs to provide the deployment requirements for each dropbox.

Providing Dropbox Deployment Requirements

To provide your deployment requirements, navigate to Projects and select Internal Pentest. Under the Scope tab, any dropboxes requiring your attention will be marked with a Setup Required tag. [1]

Dropboxes marked Awaiting Sprocket [2] are pending additional information by your Sprocket team.

To provide deployment requirements for a dropbox:

1. Click Edit on any created dropboxes
2. Complete the following required fields in the modal
   1. Select your VM Type from the dropdown. Options include OVA, VHD, and AMI. [1]
   2. Select your IP Assignment from the dropdown: [2]
      1. DHCP: No further information is needed. Save your changes.
      2. Static: Complete the following fields:
         1. IP Address
         2. Netmask
         3. DNS Servers
3. Optional fields can also be completed
   1. Nickname: The name you give the dropbox
   2. Notes: Any notes you might want included for the Sprocket team to be aware of
4. Save your changes. Sprocket is notified automatically and will build and the dropbox for you to deploy using the requirements you provided.

You can return to this page to edit dropbox settings at any time.

Dropbox Configuration Link

Once Sprocket has created the dropbox, a Configuration Link will be entered into Platform and you will be notified. These links expire within 21 days, that will also show in Platform.
To access your Dropbox Configuration Link

1. Navigate to Projects, then Internal Pentest
2. Click expand on the individual dropbox
3. Click Download your configuration [1]
4. A step by step deployment guide is linked to help assist with set-up [2]

Dropbox Deployment Guide

The appliance is a hardened Ubuntu 24.04 virtual machine that Sprocket uses to conduct the internal portion of your engagement. Once powered on, it establishes a secure outbound connection back to Sprocket. There is no inbound access required from the internet.

Summary of Key Controls

What the Appliance is

The appliance is a single hardened Ubuntu 24.04 LTS Linux host that sits on your network and acts as our testing foothold inside to mimic a thread actor who has gained access to your internal network(s).

Deployment options

The appliance is delivered as software, so a site can be covered as soon as your team can import an image. All options product the same hardened build and the same operational model.

Resource Requirements

How We Build it

Every appliance is built by an automated pipeline from source-controlled configuration. Each build is individual to you: its own hostname, its own certificate, its own credentials, its own single-use enrollment token.

1. Intake and Identity
   1. During onboarding Sprocket records the client name, image format and network addressing. That short name becomes the appliance identity used consistently for its hostname, its certificate subject, and its management record.
2. Certificate issuance
   1. A dedicated client certificate and private key are generated on our certificate authority for this appliance alone, and a tunnel address is reserved for it. No certificate is ever shared between clients.
3. Image build
   1. The pipeline starts from Canonical’s current official Ubuntu 24.04 LTS server image, applies all available updates, then runs our configuration automation to install packages, strip unneeded software, apply the hardening baseline, and place the certificate. The build runs in our own cloud environment under short-lived federated credentials rather than stored access keys.

4. Delivery

   1. The image is published to a delivery endpoint and you receive a signed download link that expires after three weeks. The link is a credential in its own right, so it is sent to you directly rather than circulated internally, and we can reissue it if it lapses before you download.

   On Credentials

   Each appliance is given a unique random administrative passphrase of at least twenty-five characters, used for that client and nowhere else at Sprocket. Certificates and passphrases are supplied to the build pipeline as masked secrets and never recorded in tickets, chat or email.

Hardening Baseline

The build removes software rather than merely disabling it, on the reasoning that a package which is not installed cannot be exploited, cannot phone home, and does not need patching.

Patching and Lifecycle

Patching happens at two points:

• when the appliance is built
• continuously while it is in service

Networking and Outbound Access

The appliance never accepts a connection from the internet. It establishes an outbound, mutually authenticated, encrypted tunnel to our infrastructure and keeps it open. All management and tester traffic rides inside that tunnel. Every arrow crossing your perimeter originates inside your network.

What do open on your firewall

The appliance needs outbound access so it can call home to Sprocket and stay managed. There are no inbound rules to create. Allow the following egress from the appliance’s IP:

Inside your network

On your side of the appliance there is no tunnelling, address translation, or non-standard routing. It reaches in-scope systems the same way any host on that segment would, from the address you assign it. If testing needs to reach subnets beyond its own, we add static routes to the appliance during deployment, and those routes are visible to you.

Keeping it in Scope

Scope is enforced on the appliance itself, not only in a document. You provide a list of addresses and ranges the appliance must never contact, and we install them as firewall drop rules covering both traffic originating on the host and traffic forwarded by tooling containers running on it.

Those rules are applied at boot and reasserted on a twelve-hour timer. The schedule is deliberate: a rule cannot be lost to a reboot, a container runtime restart, or a change made mid-engagement without being restored automatically within twelve hours.

Access Control

Three separate controls sit between a Sprocket employee and your appliance, and all three must be satisfied.

1. Individually issued certificates
   1. Every tester holds a personal X.509 certificate issued to them by name. Both ends of the tunnel authenticate. Certificates are not shared, not issued to teams, and not reused between people.
2. Multi-factor on every connection
   1. Certificate possession alone is not sufficient. Duo MFA is enforced by the tunnel server for every tester connection, so a stolen laptop or a copied certificate does not yield access on its own.
3. Source address restriction
   1. Administrative access to the tunnel infrastructure is restricted at the network layer to an explicit allowlist of Sprocket office and engineer source addresses. Connections from anywhere else are dropped before authentication is attempted.

Each tester has an individual configuration entry controlling what their session is routed to. When someone leaves the engagement or the company, that entry is removed and their certificate retired, ending their access.

Monitoring the Fleet

An appliance that has stopped functioning delays the engagement while continuing to appear operational. Sprocket monitors the fleet centrally so that degradation is identified and addressed before it affects the engagement.

Monitoring runs entirely on our infrastructure and reaches your appliance through the tunnel that already exists — so it adds no agent to the appliance, no additional egress from your network, and no new destination for your firewall to permit.

Data Handling

• Testing output is written to the appliance during the engagement and transferred to our platform for analysis and reporting, under a storage path specific to your engagement and access-controlled to your engagement team.
• Findings and results reach you through the Sprocket portal and your engagement reporting, as with any Sprocket assessment.
• Working files remain on the appliance until it is decommissioned, at which point they are destroyed with it.
• Data collected is what the engagement requires. If particular data types must not leave your environment at all, raise it during scoping so we can plan the testing approach around it.

Deployment Steps

Network Placement and Addressing

Place the appliance on an internal network segment that represents the scope of the assessment — typically a standard corporate/server VLAN with routed access to the systems in scope. Some environments require more than one appliance to reach all in-scope segments. Placement — and how many appliances are needed — is settled during the scoping and sales process. If additional appliances are needed a change order will need to be completed. If you have questions before then, reach out to support@sprocketsecurity.com.

IP addressing — choose one:

Firewall Action Items

Confirming a Successful Deployment

Once the VM is powered on and the outbound egress in Section 5 is allowed, there is nothing further for your team to do — the appliance finishes setup on its own. Let your Sprocket contact know once it's powered on (or reach out to support@sprocketsecurity.com), and Sprocket will watch for it to check in and confirm from our side.

Behind the scenes, within a few minutes of boot the appliance will automatically:

1. Obtain an IP address (DHCP or static)
2. Expand its disk to the full provisioned space
3. Establish the outbound callback tunnel to Sprocket
4. Register for out-of-band management

Decommissioning

Removal is deliberately something you can complete yourself and verify, without depending on us to act first.

1. We retire the appliance certificate

   The reserved tunnel address is released. All connectivity ends at this point, from our side, regardless of the state of the host.

2. Any management agent is deregistered

   Where a management agent was used, deregistering the host permanently revokes our ability to run commands or open sessions on it.

3. Your team powers off and deletes the appliance

   Removing the VM from your hypervisor inventory is all that is required on your side. For an AWS AMI deployment, terminate the instance and deregister your copy of the AMI.

4. Wipe expectations are agreed

   Where the appliance runs on a host you own, we agree the wipe expectation with you before the engagement closes so nothing is left ambiguous.

Powering off or deleting the virtual machine is sufficient to end all access on its own. Certificate retirement provides a second, independent termination of access.