Summary and recommendation
Veracode user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
Veracode user administration lives entirely in the platform UI at Admin > User Administration (https://analysiscenter.veracode.com/auth/index.jsp#UserAdministration).
Only users holding the Administrator role can create, edit, or deactivate accounts - there is no delegated or sub-admin tier documented.
Roles are additive, so a single user can hold multiple roles simultaneously, but access to applications is further gated by team membership.
Quick facts
| Admin console path | Veracode Platform > Admin > User Administration |
| Admin console URL | Official docs |
| SCIM available | No |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full platform administration: create/edit/deactivate users, assign roles, manage teams, configure SSO, view all scan results and reports across the organization. | Cannot perform scans directly unless also assigned a submitter or security lead role. | Only Administrators can manage other users. There is no sub-admin or delegated admin role documented. | ||
| Security Lead | View all scan results, approve mitigations, access policy reporting, manage findings across all applications. | Cannot manage users or platform configuration. | Mitigation approval authority is scoped to this role; reviewers without this role cannot approve mitigations. | ||
| Executive | Read-only access to high-level policy and compliance reports across the organization. | Cannot view raw scan findings, submit scans, or manage users. | Intended for reporting consumers only; no operational scan access. | ||
| Submitter | Upload applications and submit scans for assigned applications/teams. | Cannot view scan results unless also assigned a Results role. Cannot manage users. | Submitter and Results roles are separate; a developer who submits scans will not see results without the Results role also assigned. | ||
| Results | View scan results and findings for assigned applications/teams. | Cannot submit scans, approve mitigations, or manage users. | Access is scoped to teams the user belongs to; results for applications outside assigned teams are not visible. | ||
| Mitigation Approver | Approve or reject proposed mitigations for findings on assigned applications. | Cannot submit scans or manage users. | Distinct from Security Lead mitigation approval; check which role is required for your workflow. | ||
| Reviewer | View scan results and propose mitigations (but not approve them) for assigned applications. | Cannot approve mitigations, submit scans, or manage users. | |||
| Creator | Create new application profiles in the platform. | Cannot submit scans or view results without additional roles. | Application creation and scan submission are separate permissions requiring separate roles. | ||
| Any Scan | Submit any scan type (Static, Dynamic, SCA) for assigned applications. | Cannot view results without Results role. | |||
| API Service Account (API roles) | Programmatic access via Veracode APIs; specific API roles (e.g., Upload and Scan API, Results API) are assigned separately from UI roles. | Cannot log into the Veracode web UI. | API credentials (API ID + key) are separate from UI login credentials. API roles must be explicitly assigned; UI roles do not automatically grant API access. |
Permission model
- Model type: role-based
- Description: Veracode uses a predefined role-based access control model. Users are assigned one or more roles from a fixed set of platform roles. Roles are additive-a user can hold multiple roles simultaneously. Access to applications is further scoped by team membership; users only see applications belonging to their assigned teams unless they hold organization-wide roles (e.g., Security Lead, Administrator).
- Custom roles: No
- Custom roles plan: Not documented
- Granularity: Role-level with team-based application scoping. No field-level or object-level custom permissions documented.
How to add users
- Log in to the Veracode Platform with an Administrator account.
- Navigate to Admin > User Administration.
- Click 'Add New User'.
- Enter the required user details: first name, last name, email address, and username.
- Assign one or more roles from the available role list.
- Assign the user to one or more teams (required for application-scoped access).
- Click 'Save'. The user receives an email invitation to set their password.
Required fields: First name, Last name, Email address, Username, At least one role
Watch out for:
- Username must be unique across the Veracode platform, not just within your organization.
- Users are not automatically assigned to any team; without team assignment, application-scoped roles (Submitter, Results, Reviewer) grant no effective access.
- The invitation email may be filtered as spam; users should check junk folders.
- If SSO is enforced, the user must exist in the IdP before they can log in, even after being created in Veracode.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Enterprise (requires SSO/SAML configuration) |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Veracode documentation focuses on user administration and deactivation-style access control in the UI, while identity APIs can expose delete-style operations. Tenant-specific lifecycle behavior should be validated before assuming only one path exists.
- Log in to the Veracode Platform with an Administrator account.
- Navigate to Admin > User Administration.
- Search for or locate the target user.
- Click the user's name to open their profile.
- Uncheck the 'Active' checkbox or click the deactivate option.
- Save the change. The user can no longer log in.
| Data impact | Behavior |
|---|---|
| Owned records | Scan submissions, findings, and mitigation history attributed to the deactivated user are retained and remain visible to other users with appropriate access. |
| Shared content | Application profiles and scan results the user had access to remain intact and accessible to other team members. |
| Integrations | API credentials (API ID and key) associated with the deactivated user should be revoked separately; deactivating the UI account does not automatically invalidate API credentials per documented behavior. |
| License freed | No per-user licensing model is publicly documented; deactivation impact on license consumption is not specified in official docs. |
Watch out for:
- Deactivated users cannot be reactivated by the user themselves; an Administrator must re-enable the account.
- API service account credentials are managed separately and must be explicitly revoked to prevent continued API access after UI account deactivation.
- Usernames of deactivated accounts cannot be reused for new users due to platform-wide username uniqueness requirements.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Platform User | Access to Veracode platform UI and/or APIs based on assigned roles. No per-seat pricing is publicly documented. |
- Where to check usage: Admin > User Administration (view active user list and assigned roles)
- How to identify unused seats: Administrators can review the user list in Admin > User Administration and filter by last login date or active status to identify inactive accounts. No automated unused-seat report is documented.
- Billing notes: Veracode pricing is based on application/scan volume and product modules (SAST, DAST, SCA), not per-user seats. No per-user billing is publicly documented. Contract terms govern usage limits.
The cost of manual management
Veracode pricing is based on application and scan volume across modules (SAST, SCA, DAST), not per-user seats, so no per-seat cost is published. That said, manual provisioning carries real operational cost: there is no bulk CSV import, so onboarding a large cohort means clicking through every app and every user one at a time.
Deactivated usernames cannot be recycled, which creates friction when re-onboarding contractors - a new username must be created even if the email address is identical.
The decision
Manual administration is workable for organizations with stable, low-churn user populations and an Administrator who owns provisioning. It becomes a liability at scale: every app access change requires an Administrator, there is no self-service, and offboarding requires two distinct actions (deactivate UI account, revoke API credentials separately).
Teams with frequent contractor rotation or large developer populations should evaluate IdP-based provisioning via Okta or Entra ID SAML to reduce per-user administrative overhead.
Bottom line
Veracode's manual user management is functional but deliberately centralized - one Administrator role controls everything, roles are additive but fixed, and the platform offers no bulk import or delegated admin path.
The Submitter/Results role split and the team-scoping model mean that incomplete provisioning silently produces users who can act but cannot see, or vice versa.
For any organization managing more than a handful of users, the manual path surfaces real operational risk: deactivating a UI account does not revoke API credentials, usernames cannot be recycled, and there is no automated audit of unused access. These are not edge cases;
they are the default behavior of the platform.
Automate Veracode workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
