What is a scanner credential lifecycle?

A scanner credential lifecycle is the documented sequence of states a stored authenticated-scan credential moves through, from creation against a verified target, through scheduled and on-demand use, through periodic rotation, through revocation when the underlying account, role, or scope changes. The lifecycle exists because authenticated scans depend on a credential that is both valid (the login still works) and aligned to the scope (the role still maps to the surface the scan is supposed to test). A scan that runs against a stale credential silently degrades into either an unauthenticated scan (worst case) or a scan run at the wrong role (more common), and either outcome is a coverage failure that looks like a successful run from the activity log unless the lifecycle records the rotation explicitly.

How often should authenticated scan credentials be rotated?

Rotation cadence depends on the credential type and the underlying account class. Form login credentials backed by a service account warrant rotation on a documented interval (commonly 90 days, with shorter cadence for high-value applications) plus rotation on any role, scope, or password-policy change. Bearer tokens rotate on the issuer expiry by definition; the scanner-side discipline is to rotate the stored copy ahead of expiry rather than after the scan starts failing. Cookies inherited from a logged-in browser session are short-lived and should be re-captured per scan rather than stored long term. Basic auth credentials carry no native expiry and warrant the strictest rotation cadence because they are the most stable target for credential drift. The defensible cadence is per credential type and per asset criticality, justified against the framework rotation expectation that applies (PCI DSS Requirement 8.3 and ISO 27001 Annex A 5.17 both treat authentication information as a controlled artefact with a documented refresh cycle).

What triggers a credential rotation outside the scheduled cadence?

Six events warrant rotation ahead of the next scheduled tick. The service account password is changed at the source (a frequent silent breakage cause). The application authentication mechanism changes (cookie name change, login URL change, session storage change, MFA enforcement change). The account role changes so the credential no longer maps to the intended scope. A new scope is added that the existing role does not cover. A team member with manage_credentials permission leaves the workspace (the credential still works but the chain of custody is broken). A breach or suspected leak of the underlying account credentials. Each event has the same downstream effect: the next scan that reads the old credential either fails authentication (best case, surfaces the issue) or authenticates with the wrong identity (worse case, produces output that looks correct and is wrong).

How is a service account different from a personal account for authenticated scanning?

A service account is an account created specifically for the scanner, owned by the security team or the application owner, with documented role, scope, and rotation policy. A personal account is the everyday login of a team member that is reused for the scan. Service accounts are the defensible pattern for three reasons. Personal accounts pick up role changes, password rotations, and MFA enrolment events the scanner cannot anticipate, so coverage breaks unpredictably. Personal accounts attribute scanner activity to a real person in the application audit log, which conflates scanner traffic with human activity and breaks both audit trails. Personal accounts cannot be rotated without breaking the team member who owns them, so rotation either does not happen or causes unrelated friction. A service account scoped to the test role, named after the scan programme, and rotated on a documented cadence produces an audit trail that survives team changes and reads cleanly to an auditor.

How do you rotate credentials without breaking scheduled scans?

Rotation without coverage gaps requires three operational rules. First, rotate ahead of expiry rather than after a failure. A schedule-driven rotation reminder (calendar alert, ticket, or platform-level expiry warning) fires at a configurable lead time so the new credential is staged before the old one stops working. Second, run a verification scan against the new credential before the old credential is revoked. The new credential authenticates at the same role and reaches the same surface as the old one; without verification, the rotation can degrade scope silently. Third, hold the rotation event in the audit trail with the rotation reason, the new credential metadata (label, type, target), and the verification result. The schedule continues to point at the credential record rather than at the secret, so the rotation updates the secret in place and the schedule keeps running on the next tick. Programmes that rotate by deleting and recreating tend to drop schedules; programmes that rotate the underlying secret on the same record keep cadence intact.

What is the difference between credential rotation and credential revocation?

Rotation is replacing the secret on a record that is still in use; the credential identifier, the verified domain binding, and the scan schedules pointing at it stay intact. Revocation is the end of the lifecycle; the record is removed and any future scan that referenced it must use a different credential. The two events have different audit implications. Rotation reads as continued credential operation under a refreshed secret; revocation reads as the end of the credential is operating window. A scan record that pairs against a revoked credential is read by an auditor as either a coverage gap from that point forward (if no replacement was issued) or as a clean handoff to the replacement (if the replacement is recorded). Programmes that conflate the two create audit ambiguity; programmes that treat them as distinct lifecycle events produce a record that reads precisely.

How should mid-scan credential invalidation be handled?

A credential can be valid at scan start and invalid mid-scan for several reasons. The application enforces idle timeout and the scan waited too long between requests. The application detected anomalous access patterns and locked the session. A coincidental rotation at the source (a security alert at the IdP, an admin-side lockout) invalidated the cached secret. The session storage was cleared by an unrelated maintenance event. The scanner-side discipline is to detect the invalidation through diagnostic signals (HTTP 401 responses, redirect to login pages, session missing errors), pause or fail the affected modules cleanly, record the invalidation as a scan event with the timestamp and the affected module set, and stop replaying the broken session. A scanner that ignores mid-scan invalidation produces output where a subset of modules ran authenticated and a subset ran unauthenticated, and the resulting findings are unsafe to compare across the scan.

How do bearer tokens differ from cookies for rotation purposes?

Bearer tokens carry an explicit expiry in the token payload (most commonly a JWT exp claim) and rotate at the issuer cadence. The scanner-side rotation question is not whether to rotate but when to refresh the stored copy ahead of expiry. Programmes that store the bearer with no expiry tracking discover the rotation only when a scan starts returning 401 responses. Cookies are the inverse: most session cookies carry no usable expiry from the scanner side, the cookie value depends on the application session manager, and cookies tend to invalidate on backend events (idle timeout, password change at the user, server restart in some session storage models). The defensible pattern for bearer tokens is to rotate the stored copy ahead of the issuer expiry; the defensible pattern for cookies is to capture the cookie per scan from a freshly-logged-in browser session rather than treating it as a long-lived credential. Form login credentials sit in between because the scanner can run the login flow at scan time, but the underlying account credential is what actually rotates.

What evidence does a credential lifecycle leave for auditors?

The audit-quality evidence pattern records four event classes per credential. Creation events (who created the credential, against which verified domain, with which credential type, on which date). Usage events (which scan executions referenced the credential, when, with what outcome). Test events (when the credential was test-pinged, by whom, with what outcome). Revocation events (when the credential was removed, by whom, with what reason). Auditors read these events not as paperwork but as evidence the credential operated under control across the observation period. ISO 27001 Annex A 5.17 (authentication information), SOC 2 CC6.1 (logical access controls), and PCI DSS Requirement 8 (identify users and authenticate access) all read credential operation through these four event classes. A credential lifecycle that stores the secret without recording the events satisfies the storage bar and fails the operating-effectiveness bar.

How do you separate credential ownership from credential rotation responsibility?

A scanner credential has two stakeholders that are not always the same person. The credential owner is the account holder at the application (the person who owns the underlying account, knows when the password rotates, and signs off on the role the credential maps to). The credential rotator is the workspace member with the manage_credentials permission who updates the stored secret. In small teams these are usually the same person; in larger programmes they diverge by design. The defensible pattern names both roles in the credential metadata and routes rotation reminders to both: the owner produces the new secret, the rotator updates the stored copy, and the audit trail names both for the rotation event. Programmes that conflate the two end up with stored credentials that the rotator does not understand and the owner does not know are stored, which is the most common failure mode for credential drift.

How does SecPortal handle scanner credential rotation and lifecycle?

SecPortal stores authenticated scan credentials in the auth_credentials table with AES-256-GCM authenticated encryption. A one-byte key version prefix is written into every ciphertext, and the platform retains a configured previous key for fallback decryption, so the encryption key can rotate without a migration window. Cookie, bearer token, basic auth, and form login credentials are supported, each bound to a verified_domains row in the same workspace so a credential cannot point at a target the workspace has not proved control of. Credential creation, test pings, and revocation are recorded as events in the activity log with the acting user, the credential label, type, and verified domain. The last_used_at timestamp is updated on every scan execution that references the credential, so the workspace can see which stored credentials are still active and which are dormant. The workspace MFA enforcement promotes sessions to AAL2 before the credentials settings tab is reachable, so credential changes inherit the workspace second-factor requirement. The platform does not expose plaintext credentials to the browser after creation, does not return them on list endpoints, and never writes them into scan results, finding evidence, or activity metadata.

← Back to Scanner Information

Scanner guide16 min read

Scanner Credential Rotation and Lifecycle: A Production Guide

Most authenticated scan failures attributed to coverage are credential failures wearing a different label. A scanner runs with a stored credential, the credential drifts at the source (password change, role change, expiry, MFA enrolment, account lockout), and the next scheduled scan either silently fails authentication or runs at the wrong role. The output reads as a successful scan with a smaller findings count, which looks like remediation and is a coverage drop. The fix is not better authentication scripts; the fix is a documented credential lifecycle that rotates ahead of failure, records the rotation event, and verifies the new credential reaches the same surface as the old one.

This guide covers how to set rotation cadence by credential type and asset class, how to rotate without breaking scheduled scans, when to revoke instead of rotate, how to handle mid-scan invalidation, what auditors read in a credential lifecycle, how service accounts change the calculus, and how internal security, AppSec, vulnerability management, and GRC teams operate credential lifecycle as part of the scanning programme rather than as a one-off setup task.

Credential drift is the silent coverage killer

An authenticated scan depends on three things being true at scan time. The credential is still valid. The credential maps to the scope the scan is supposed to test. The authentication mechanism the scanner expects has not moved. Any one of those three can change at the source between scheduled runs without anyone updating the stored credential, and the next scan inherits the drift.

The drift modes are predictable. Service account passwords rotate at the source on the organisational password policy. Bearer tokens expire at the issuer cadence. Cookies invalidate on idle timeout, password change at the user, or session storage events the application owns. Roles shift when the test role is repurposed for a new product line or a permission set is reduced for least-privilege reasons. MFA gets turned on for the account class without an exemption for the scanner. The login URL moves when an authentication redesign ships. Each one converts a working stored credential into one that either fails authentication outright or, worse, succeeds at the wrong scope.

The defensible read is that authenticated scan coverage degrades faster than any other scanner discipline because the underlying credential operates outside the scanner is control. The discipline that holds up is to treat the stored credential as a perishable artefact with a documented refresh cycle, not as a one-time setup. The authenticated scanner failure modes guide covers the six failure classes the drift produces; this guide covers the upstream policy that prevents most of them.^4,5,7

Rotation cadence by credential type

One global rotation cadence across all stored credentials over-rotates the short-lived ones and under-rotates the long-lived ones. The defensible cadence is per credential type and per asset class, justified against the framework rotation expectation that applies. The table below sets reasonable starting cadences that teams tune based on the asset criticality, the underlying account class, and the scan schedule the credential supports.

Credential type	Recommended rotation	Trigger events
Form login (service account)	90 days for production, 30 days for high-value apps	Password change at source, role change, MFA enrolment, login URL change.
Bearer token (long-lived)	Ahead of issuer expiry, lead time matched to scan cadence	Token expiry approaching, scope change, issuer key rotation, account class change.
Bearer token (short-lived)	Re-issue per scheduled run from a refresh-token flow	Refresh token rotation, scope change at issuer.
Cookie (session)	Re-capture per scan from a fresh logged-in browser session	Idle timeout, password change at user, server-side session invalidation.
Basic authentication	60 days, with strict per-asset cadence on high-value targets	Password change at source, account move, scope change.

Two policy rules make the cadence easier to defend. First, document the rotation cadence in the scan policy alongside the scan cadence rather than as a separate artefact: rotation is an input to scan cadence, not an unrelated control. Second, justify the cadence against the framework floor that applies to each asset (PCI DSS Requirement 8.3 for cardholder estate, ISO 27001 Annex A 5.17 for general information assets, NIST SP 800-63B for federal-aligned authentication). The page on scan scheduling and baseline cadence covers the cadence the rotation has to feed.^1,2,4

Six events that trigger rotation off-cycle

Scheduled rotation handles the steady state. Six event classes warrant rotation ahead of the next scheduled tick because the credential has effectively drifted regardless of its calendar age.

Source-side password change on the underlying account

The owner of the service account (or the IdP, for managed accounts) rotates the password on the organisational policy. The stored credential keeps the old password and the next scan starts failing authentication. The fix is a rotation reminder routed to both the credential owner and the credential rotator so the stored copy is updated before the next scheduled run.

Role or scope change on the credential

The test role gets repurposed, the permission set is reduced for least-privilege reasons, or a new product line is added that the existing role does not cover. The credential still works but the scope it reaches no longer matches the scan policy. The fix is a rotation that records the new role explicitly so the audit trail shows the role under which the scan operated.

Authentication mechanism change at the application

Login URL change, cookie name change, MFA enforcement on the account class, SSO redirect change, password policy change that invalidates the stored credential format. The credential representation has to move with the application; rotation is the moment that captures the new representation alongside the new secret.^7,8

Team member with manage_credentials leaves the workspace

The credential still works but the chain of custody is broken. NIST SP 800-63B and ISO 27001 Annex A 5.17 both treat authenticator chain of custody as an evidence axis distinct from authenticator validity. The disciplined response is to rotate the stored secret on the leaver event so the post-rotation custody chain starts with the remaining team.^2,4

Suspected leak or breach of the underlying account

A security alert at the IdP, a breach disclosure that names the account class, a phishing event that may have captured the secret, or any anomalous access pattern that suggests the credential is no longer secret. Rotation is the immediate response, paired with revocation of any sessions the stored credential authored.

Token issuer rotation

For bearer tokens, the issuer rotates its signing key, the OAuth client secret, or the token format. The stored token continues to work until the next issuer validation cycle and then breaks abruptly. The disciplined pattern is to track the issuer rotation calendar and pre-rotate the stored token rather than waiting for authentication to start failing.^9,10

Rotation without breaking scheduled scans

A rotation that drops the schedule, the verified domain binding, or the scan history converts a maintenance event into a coverage gap. Three operational rules keep scheduled coverage intact across rotations.

Rotate ahead of expiry, not after failure

A schedule-driven rotation reminder fires at a configurable lead time so the new credential is staged before the old one stops working. Programmes that rotate reactively (after the first 401 in a scan log) lose at least one scheduled run per rotation cycle and produce diff output that mixes regression with coverage drop. The lead time should match the scan cadence: a weekly schedule warrants a seven-day rotation lead time so the rotation happens between runs.

Verify before revoking the previous secret

Run a verification scan or test ping against the new credential before the old credential is revoked. The verification confirms the new credential authenticates at the same role and reaches the same surface as the old one. Without the verification step, rotation can degrade scope silently when the new account is subtly different from the old (a permission set reduction, an MFA difference, an account that is in a different organisational unit). The page on scanner coverage and limits covers how to read coverage so a verification run can be compared cleanly to the pre-rotation baseline.

Update the secret on the same record, do not delete and recreate

Scheduled scans point at a credential record, not at a secret. Rotation that deletes the record and creates a new one drops every schedule that referenced the old record. Rotation that updates the secret on the same record keeps the schedules pointing at the live credential and keeps the audit trail linear. Programmes that rotate by deleting and recreating tend to discover the schedule breakage on the next missed scheduled run; programmes that update in place keep cadence intact across the rotation event.

Rotation versus revocation

Rotation and revocation are different lifecycle events with different audit implications. A clean credential record makes the distinction explicit so the audit trail reads precisely.

Event	When to use	Audit read
Rotation	The credential is still in scope; the secret needs to refresh.	Continued credential operation under a refreshed secret. The scan cadence continues uninterrupted.
Revocation	The credential is end-of-life; no replacement is needed against this scope.	End of the credential operating window. Scans that pointed at it must reference a different credential or be retired.
Replacement	The credential is revoked, and a new credential is created (different label, different account, different role).	A clean handoff between two credential records, both visible in the lifecycle.

The most common audit ambiguity comes from programmes that revoke a credential and stage a new one as if it were a rotation. The audit trail shows a deletion and a creation, with nothing tying them together. The defensible pattern is to record the replacement as a paired event (revocation reason references the new credential, new credential references the predecessor), so the lifecycle is reconstructable from the activity log.

Service account discipline for authenticated scans

The strongest rotation policy still fails if the credential is anchored to a personal account that cannot be rotated independently. Every authenticated scan against production warrants a service account that exists only for the scanner and is owned by the security team or the application owner.

Account naming. Name the account after the scan programme (for example, scanner-yourapp-prod) so the application audit log attributes scanner activity to a clear identity rather than a real user.
Role scoping. Assign the lowest role that still reaches the surface the scan is supposed to test. Authenticated scans that run as administrators produce findings that look severe and are not always reachable from realistic roles; lower-privilege scopes mirror the actual attack surface.
MFA exemption (or scanner MFA harness).Decide deliberately whether the account is MFA-exempt or whether the scanner runs an MFA harness for it. Both are defensible; the failure mode is leaving the question undecided so MFA enrolment lands silently and breaks the scan.
Rotation policy alignment. Align the service account password policy to the scanner rotation cadence rather than the human user policy, so rotation events do not happen at unpredictable times.
Owner assignment. Name a credential owner in the application directory. Rotation reminders route to the owner; the owner generates the new secret; the credential rotator updates the stored copy.
Documented retirement path. When the service account is retired (programme ends, asset decommissions), the credential is revoked and the application directory account is removed. The two events are recorded in the lifecycle so the audit trail closes cleanly.

Programmes that build authenticated scan coverage on personal accounts inherit every personal-account event the user owns: password rotations, MFA enrolment, role changes, departures. Coverage breaks unpredictably and the audit trail mixes scanner activity with human activity. Service accounts isolate the scan lifecycle from the user lifecycle and produce evidence that survives team change.^7,8,12,13

Mid-scan credential invalidation

A credential can be valid at scan start and invalid mid-scan for several reasons. The scanner needs to detect the invalidation, fail the affected modules cleanly, and record the event so the resulting findings can be read accurately.

Idle timeout during long-running modules

The application enforces an idle timeout that fires between requests on a slow module. Subsequent requests redirect to the login page or return 401. The disciplined response is to detect the redirect or status code, attempt a session refresh from the stored credential, and pause the module if the refresh fails. The affected modules are marked as inconclusive rather than as no-finding modules.

Anomaly detection lockout

The application detects anomalous access patterns from the scanner traffic and locks the session. Sometimes this is intentional (the scan is exercising rate limits the application is supposed to enforce); often it is a side effect of scan concurrency. The page on scanner rate limiting and throttling covers how concurrency and rate decisions intersect with mid-scan lockouts.

Coincidental rotation at the source

A security alert at the IdP, an admin-side lockout, or a planned rotation lands during the scan window. The scanner authenticates at the start, runs for some time, and then starts seeing 401 responses. The rotation event is recorded in the source system; the scan log has to capture the moment the authentication state changed so the resulting findings can be partitioned into pre-rotation and post-rotation segments.

Session storage cleared

The application restarts, the session storage backend is restarted, or a maintenance event clears the session table. The stored cookie is now invalid even though the credential has not changed. The scanner detects the invalidation via redirect-to-login signals and records the event. The next scheduled scan re-authenticates from the stored credential and recovers automatically.

How compliance frameworks read credential lifecycle

Auditors read credential lifecycle through three indirect lenses. The first is rotation cadence operation: a rotation policy on paper that does not produce rotation events in the activity log fails the operating-effectiveness bar. The second is chain-of-custody continuity: a stored credential whose owner has left the workspace without a rotation event reads as a chain-of-custody gap regardless of whether the credential still works. The third is end-of-life cleanliness: a credential whose underlying account is deactivated without a corresponding revocation event reads as a stale credential record.

PCI DSS v4.0 Requirement 8 sets controls on user identification and authentication, including specific cadence on password rotation (Requirement 8.3) and immediate revocation on access termination (Requirement 8.2.5). Stored scanner credentials are in scope when they authenticate against the cardholder data environment.¹
ISO 27001:2022 Annex A 5.17 (authentication information) treats authenticators as controlled artefacts with a documented refresh cycle and chain-of-custody record. Scanner credentials inherit this control when they target ISMS-scoped assets.²
SOC 2 CC6.1 (logical and physical access controls) reads the credential lifecycle as part of the access-control evidence across the observation period. A credential record without rotation, test, and revocation events fails the operating-effectiveness read.³
NIST SP 800-63B (Authentication and Lifecycle Management) names the explicit lifecycle events (binding, authentication, renewal, revocation) and the evidence each should produce. Scanner credentials follow the same model when they authenticate against systems aligned to NIST 800-53.⁴
NIST SP 800-53 control IA-5 (Authenticator Management) sets discrete obligations for authenticator distribution, storage, rotation, and revocation. The control reads as failed if the rotation events are not recorded across the observation period.⁵

The shared pattern is that storage alone does not satisfy the requirement; the requirement is satisfied by the events the storage produces over time. A credential record with creation, rotation, test, and revocation events spread across the observation period reads as operating credential management; a record with only a creation event reads as a static artefact regardless of how strong the encryption is.

Operational checklist for a defensible credential lifecycle

At policy design

Rotation cadence is documented per credential type and per asset class.
Off-cycle rotation triggers (six event classes above) are named in the policy.
Service accounts are required for production authenticated scans rather than personal accounts.
Credential owner and credential rotator roles are named separately.
The MFA exemption decision (or MFA harness model) is made deliberately per account.

At credential creation

Credential is bound to a verified domain in the workspace.
Credential type, label, target URL, and credential owner are captured.
A test ping confirms the credential authenticates at the intended role.
The creation event is written to the activity log with the acting user.
The next rotation date is set on the policy schedule.

At rotation

The new secret is staged ahead of the old one is expiry, not after failure.
A verification scan or test ping confirms the new credential reaches the same surface.
The secret is updated on the existing credential record so schedules stay live.
The rotation event is recorded with the rotation reason and the new last_used_at baseline.
The next rotation date is set on the policy schedule.

At revocation

The revocation reason is recorded (programme end, account deactivation, breach, replacement).
If a replacement credential is being staged, the two records reference each other.
Schedules pointing at the revoked credential are reassigned or retired.
The activity log records the revocation event with the acting user.
The application directory account is deactivated where applicable.

For internal security and AppSec teams

Internal security teams, AppSec teams, vulnerability management teams, and security engineering teams operate authenticated scans against production. The credential lifecycle is the discipline that turns a one-time scan setup into a programme that survives team change, role change, and infrastructure change without rebuilding from scratch every quarter.

Anchor authenticated scans to service accounts, not personal accounts, so coverage is independent of who owns the test login.
Document rotation cadence per credential type and per asset class so the cadence is auditable rather than a tester preference.
Rotate ahead of expiry rather than after failure so scheduled cadence does not lose runs to credential drift.
Verify the new credential reaches the same surface as the old before revoking the previous secret.
Hold rotation, test, and revocation events on the same record the scans run against so the audit view reads from the live engagement.

For internal security teams, AppSec teams, vulnerability management teams, and security engineering teams, the operating commitment is that credential lifecycle is part of the scan policy, not part of the runbook. A policy without rotation events fails the audit; a runbook without policy guidance fails the team change. The audit evidence half-life research covers how authentication evidence ages between assessments, and the credential handover workflow covers the related discipline of moving credentials cleanly between tester and team.

How SecPortal handles scanner credential rotation and lifecycle

SecPortal stores authenticated scan credentials in a dedicated table with AES-256-GCM authenticated encryption. The encryption model is built for rotation: a one-byte key version prefix is written into every ciphertext, decryption falls back to a configured previous key when the current key cannot decrypt a record, and the storage stays readable through a key rotation without a migration window.

Encrypted storage with rotation-safe ciphertext

The platform encrypts every credential payload with AES-256-GCM, writes a versioned ciphertext that supports key rotation through fallback decryption, and never stores plaintext at rest. Plaintext is only reconstructed in memory at scan execution and is never written to logs, scan results, or activity metadata. The encrypted credential storage feature covers the cryptographic detail.

Cookie, bearer, basic, and form login support

Four credential types cover the authenticated surface most teams operate. Each type rotates differently, and the platform keeps the storage shape consistent so rotation is the act of updating the secret on the same record rather than rebuilding the credential. The authenticated scanning feature covers the per-type behaviour.

Verified domain binding

Every credential references a verified_domains row in the same workspace. A credential cannot be created without a verified domain, and the target URL hostname is checked against the verified domain at creation, so a credential cannot be aimed at an unauthorised target even by a malicious operator with manage_credentials. The domain verification feature covers the verification flow.

Activity log on creation, test, and revocation

Credential creation, test pings, and revocation are recorded as activity events with the acting user, the credential label, type, and verified domain. The events flow into the same activity feed that records findings, engagements, scans, and team changes, so credential lifecycle is reviewable from one place. The activity log feature covers the audit trail surface.

Last used timestamp for dormancy detection

Each scan that uses the credential updates the last_used_at timestamp, so the workspace can see which stored credentials are still active and which are dormant. A credential that has not been used in months is a candidate for revocation rather than rotation; the dormancy signal makes the cleanup decision auditable.

MFA-gated credentials settings

Workspace MFA enforcement promotes sessions to AAL2 before the credentials settings tab is reachable, so credential changes inherit the workspace second- factor requirement. A credential rotation is itself an authenticator-management event and is gated by the same controls that gate other sensitive workspace actions. The multi-factor authentication feature covers the MFA enforcement model.

The credential record, the schedules that reference it, and the scan executions that ran with it all land on the engagement so the audit view reads from the same record the operators run on. The continuous monitoring feature holds the schedule that drives recurring authenticated scans, and the findings management feature holds the finding lifecycle the credentials make possible.

Related scanner discipline

Credential lifecycle depends on the surrounding scanner disciplines and feeds back into them. The pages below cover the connected decisions.

Authenticated scanner failure modes covers the six failure classes that credential drift produces and how to read diagnostic signals when the scan log shows authentication problems.
Scan scheduling and baseline cadence covers the cadence the rotation has to feed and how to read the diff across scheduled runs.
Scanner coverage and limits covers how to read coverage so a verification run after rotation can be compared cleanly to the pre-rotation baseline.
Vulnerability scanner false positives covers how authentication state interacts with finding triage, especially for authentication-dependent vulnerability classes.
Scanner rate limiting and throttling covers how concurrency and rate decisions interact with mid-scan credential invalidation and lockout events.
Credential handover for pentests covers the related discipline of moving credentials cleanly between tester and team rather than across stored-secret rotation.

For the wider operating model the lifecycle plugs into, the security testing program management workflow covers how authenticated scan coverage fits into a programme that also runs external, code, and manual testing, and the continuous security monitoring guide covers the programme-level discipline that scheduled authenticated scans are one input into.

Scope and limitations of this guide

Credential lifecycle is a programme discipline, not a configuration setting. No rotation policy makes a personal account a service account, no schedule replaces a verification scan after rotation, and no encryption model removes the obligation to record the rotation events. The lifecycle question is whether the credential is valid, in scope, and recorded; the policy question is how the team operates each axis as part of the scan programme.

Lifecycle claims that depend on a single annual rotation almost always understate the change axis. Lifecycle claims that decompose into cadence plus event-driven rotation, that pair the rotation with verification, and that hold the events on the same record the scans run against are the claims that survive both the audit and the team change.

Frequently Asked Questions

Sources

Operate credential rotation on the live engagement record

SecPortal encrypts authenticated scan credentials with AES-256-GCM, supports cookie, bearer, basic, and form login types, binds every credential to a verified domain, and records creation, test, and revocation events in the activity log so the rotation cadence reads as operating credential management rather than as a static artefact.

Start free See credential storage