Skip to content
English
  • There are no suggestions because the search field is empty.

What Types Of Credentials Does Edgescan Support?

Edgescan supports all of the common authentication mechanisms and has the ability to handle bespoke auth mechanisms also.

Version Number: v1.0.0

Published Date: 27 Mar 2026

____________________________________________________________________________

Edgescan supports all standard authentication types for accessing your technology. When creating a shared credential using the process highlighted here, you can add the following types of credentials into the platform.

Supported authentication types and common use cases

Login Form (Dynamic login forms)
Used for standard web login pages that take a username/email, password, and any additional fields your app requires (e.g. tenant ID, one-time code). Supports multi‑step flows via browser recordings and MFA for stronger security.

Basic Auth
HTTP Basic Authentication sent on each request. Common for simple, internal, or legacy web services and APIs where a static username/password pair is acceptable.

Token (Bearer / API key)
Static bearer tokens or API keys sent in a header (e.g. Authorization: Bearer <token> or API-Key <token>). Common for API integrations and service‑to‑service authentication where you don’t have an interactive login form.

OAuth 2.0
Standards-based token-based authentication. Supports Client Credentials, Authorization Code, and Password grants, making it suitable for both SSO-enabled user logins and machine‑to‑machine integrations.

NTLM
Windows NTLM / HTTP authentication. Typically used for internal Windows-based web applications and services that rely on domain credentials.

SSH
SSH credentials (password or key pair) for authenticating to servers and network devices during network-level scans.

SMB
Windows file sharing / SMB credentials, used to authenticate against file shares and Windows hosts during network-level scans.

ESXi
VMware ESXi hypervisor credentials, used when scanning virtualisation infrastructure directly.

Login Form - Dynamic Fields

Login Form credentials use dynamic fields, allowing you to model exactly what your application's login form requires.

  • Click Add Form Field to add a field

  • Enter a Field Name (e.g. username, email, password) and its Value

  • Restrict visibility: If enabled, the field's value is masked in the UI (*****) and the restriction cannot be reversed without deleting and recreating the field. Enable this for passwords and any sensitive values.

  • At least one field is required

  • Field names must be unique within a credential

Example: If your login form asks for only an email address, add a single field named email. If it requires email, password, and a one-time code field, add all three. The form adapts to whatever your application needs.

Token - Additional Fields

Beyond the token value itself, Token credentials include:

  • Header Prefix (default: Bearer) - determines how the token is sent in HTTP requests. Update this if your API uses a different scheme - for example, Token or API-Key.

  • Expires At (optional) - the date and time when the token expires, in ISO 8601 format (e.g. 2026-12-31T23:59:59Z). Leave blank if the token does not expire or the expiry is not known.

NTLM - Optional Fields

NTLM credentials include two optional fields alongside the required username and password:

  • Domain - the Windows domain to authenticate against. Leave blank if not required by your environment.

  • Workstation - the workstation name for the NTLM authentication request. Leave blank if not required.

SMB - Optional Field

SMB credentials include an optional Domain field for Windows domain authentication. Leave blank if not required by your environment.

SSH - Authentication Types

SSH credentials support two authentication methods:

  • Password: Enter a username and password.

  • Key pair: Enter a username, private key, and public key.

OAuth - Configuration

OAuth credentials require the following details from your OAuth provider:

  • Client ID - identifies your application to the authorization server

  • Client Secret - authenticates your application (keep this secure)

  • Access Token URL - the endpoint where the scanner requests access tokens (e.g. https://auth.example.com/oauth/token)

  • Scopes (optional) - the permission scopes to request

Additionally, select the Grant Type that matches your application's OAuth flow:

 

Grant Type

When to use 

Client Credentials

Machine-to-machine authentication; no user involved

Authorization Code

User-facing OAuth flow with a callback URL

Password

Direct username/password exchange for an OAuth token
 
 

If you select Authorization Code, an additional Callback URL field appears - enter the redirect URI registered with your OAuth provider.