VulcanGov Secure Configuration Guide

Version 1.4 · Updated 2026-09-12 · FedRAMP ID FR2619254906 · Machine-readable: scg.json · Trust Center home

Recommendations for securely operating VulcanGov for your agency. VulcanGov is delivered secure-by-default: the sections below describe the shipped configuration (verified against the deployed code and live identity-provider policy) and the few choices your agency makes.

Authentication

Two-factor authentication is enforced by policy for direct application sign-ins (catch-all sign-on rule; re-authentication every 12 hours) — not a per-user option. Two disclosed exceptions: (a) agency-federated logins are single-factor AT OKTA because multi-factor authentication is performed upstream by the agency identity provider (e.g. HUD OIG via SAML/Entra) — the factor is enforced, just at the IdP; and (b) a dedicated DAST security-scanner service account is password-only, restricted to the scanner's fixed egress IP zone. Group hygiene: membership of a federated single-factor group is a security setting — adding a non-federated user to one grants single-factor sign-in. As of 2026-08-25 the only active federation is agency SAML; a non-production federation that had been active in the tenant was deactivated. A small number of provider-operated test accounts remain in a federated group for supportability testing; they are provider-controlled, hold no agency data access, and are tracked for removal.
Phishing-resistant authenticators are available and recommended: Okta Verify and passkeys (WebAuthn). Phone/SMS and security questions are disabled deployment-wide.
Agency-federated single sign-on is supported: agencies may federate through their own identity provider, with multi-factor authentication enforced at the agency IdP.
Email one-time-passcode remains available while current pilot users complete migration to phishing-resistant factors; its retirement is a dated commitment: phishing-resistant multi-factor authentication for all users by 2026-12-15, with the email factor removed as an authentication method after the enrollment campaign (baseline 2026-09-11: 59 of 73 active users without a phishing-resistant factor; 0 privileged users without). Recommended agency posture: enroll users in Okta Verify or passkeys on day one.

Top-level administrative accounts

What counts as top-level here. Two kinds of account control enterprise access, and they are different things. (a) *Your* agency's top-level administrators, who control your organization's access, membership and sharing inside VulcanGov. (b) The *provider's* top-level administrators, who control the service itself. This section covers both, because your risk depends on how each is protected, and because the settings in the next few items can be operated only by one or the other.
Accessing your agency's top-level accounts. Agency administration is reached only through an authenticated VulcanGov session; there is no separate administrative console or URL for agency staff, and no local administrator password. Sign-in follows the Authentication section above: two-factor is enforced by policy, or is enforced upstream at your own identity provider if you federate. Recommended posture: hold agency administrator rights on named individual accounts enrolled in a phishing-resistant authenticator (Okta Verify or a passkey), never on a shared or role mailbox, and never on an account that also receives external mail.
Configuring and operating them. Agency administrator rights are granted per user by an existing agency administrator; there is no self-service escalation path and no default administrator. Every grant and revoke is recorded in the audit trail with the acting identity and timestamp. Recommended posture: keep the number of agency administrators to the smallest workable set, review the list on a fixed cadence you choose, and treat an administrator who has not signed in during a full review period as a candidate for removal rather than a dormant convenience.
Decommissioning them. Removing an agency administrator is immediate and takes effect on the next authorization check, not at next sign-in — an active session does not retain administrative rights after the grant is withdrawn. If you federate, deprovisioning the user at your own identity provider is the authoritative action and propagates here; if you do not, removal in VulcanGov is authoritative. Recommended posture: withdraw administrative rights first and delete or disable the account second, so no window exists in which a departing administrator holds rights on an account nobody is watching. Re-check group membership after any bulk directory change: membership, not role name, is what grants access.
Settings only an agency top-level administrator can operate, and what they mean. (i) *Granting and revoking agency administrator rights* — the only setting that can create another account with this same reach; treat a change here as the highest-impact action available to you. (ii) *Organization membership* — a user with no organization assignment sees no tenant content, so adding one is the act that exposes agency data to an identity; membership is assigned against your verified email domain or by explicit invite. (iii) *Enabling user file uploads* — default-deny per user and gated behind an explicit dual-consent administrative grant; enabling it changes what content enters the boundary, so it is deliberately not self-service. (iv) *Identity-provider federation for your agency* — choosing to federate moves multi-factor enforcement upstream to your IdP; the factor is still required, but you become responsible for enforcing it, and a weakening of your IdP's policy weakens sign-in to VulcanGov with no visible change here.
The provider's top-level administrative accounts. Stated so you can judge them rather than assume them. Two control planes: the identity provider (Okta for Government, `vulcan-app.okta-gov.com`) and the cloud environment (AWS GovCloud, administered through AWS IAM Identity Center from a dedicated management account). Okta Super Administrator is held by two named provider staff accounts, both identified on the in-boundary domain; there is no shared Okta administrator account. One non-person break-glass identity exists on the cloud side — a single console-only user in the management account, enrolled in multi-factor authentication and holding no access keys, so it cannot be used programmatically. It is disclosed here rather than described as absent. Cloud administrator access is not held by individuals directly: it is granted by a single `AdministratorAccess` permission set assigned to one group whose membership is two named provider staff, with a 12-hour maximum session; two further permission sets (`Engineer-Security`, `Engineer-Standard`, 8-hour sessions) carry narrower rights for day-to-day work. Provider administrative surfaces *inside the application* are separate again and are described under Administrative access above.
How the provider's top-level accounts are protected. All provider administrator sign-ins go through the identity provider with multi-factor enforced, and every Super Administrator account is enrolled in at least one phishing-resistant authenticator (WebAuthn). Administrative rights delegated below Super Administrator are scoped rather than global: the one delegated role in use grants user- and group-management permissions bound to a single named group each, not to the directory. Cloud account root. In AWS GovCloud (US) the account root has no console sign-in path — the GovCloud console offers IAM user sign-in only — and cannot be issued access keys. Verified across every account in the environment: no root access key exists in any of them. Provider administration is performed entirely through federated identities in AWS IAM Identity Center; no root credential is in routine use, and none is available to be misused. An assessor querying the IAM account summary will see `AccountMFAEnabled: 0` in every account. That reflects the absence of a root console credential to attach an authenticator to, not an authenticator left unenrolled, and the provider does not present it as a remediable finding. One disclosure. Until 2026-08-25 two of the four Okta Super Administrator accounts were identified on corporate mail domains outside the FedRAMP boundary. Both have since had that role removed, and administrator identity is now consolidated onto the in-boundary domain; a further unused administrator account on a retired domain was deprovisioned the same day. The history is stated rather than the end state alone, so the change is visible to a reader comparing revisions.
Settings only a provider top-level administrator can operate, and what they mean for you. (i) *Sign-on and authenticator policy* — the rules that enforce two-factor, set the 12-hour re-authentication interval, and disable phone/SMS and security questions deployment-wide; a change here changes the authentication guarantee for every tenant at once. (ii) *Identity-provider federation configuration* — adding, altering or activating a federated identity provider changes who can obtain an identity in the service; on 2026-08-25 the provider deactivated a non-production federation that was active in the tenant, and the only federation now active is agency SAML. (iii) *Group membership that policy keys on* — some sign-on rules apply to named groups, so group membership is a security setting and not an administrative convenience. (iv) *Cloud administrator assignment* — adding a member to the cloud administrator group grants administrative rights across every account in the environment. (v) *Audit-trail configuration* — disabling or reconfiguring cloud audit logging would reduce what can later be reconstructed; audit trails are enabled with log-file validation in every account, and the writing role cannot delete objects from the evidence store.
How to check these claims rather than trust them. The counts above are point-in-time and will change. If you want them verified as of a specific date, request the provider's current administrative-account inventory through the FedRAMP Security Inbox listed in the Vulnerability Disclosure section; the provider maintains it as dated evidence and supplies it to agency customers and assessors on request. Where a statement in this section is a commitment rather than a measurement — root MFA enrolment, identity consolidation — it is named as such above rather than written as though already done.

Privileged accounts

What counts as privileged here. Below the top-level accounts described above, three kinds of account carry rights that ordinary users do not. (a) *Agency scoped administrators* — members of your organization's `<Organization> Customer Admins` group in the identity provider, who administer your own users through the customer administration console. (b) *Agency users holding capability or permission grants* — membership of `<Organization> Permission - …` and `<Organization> User Group - …` groups, which switch specific administrative permissions and product capabilities on for named users. (c) *Provider engineering and service identities* — the two narrower cloud permission sets (`Engineer-Security`, `Engineer-Standard`), delegated identity-provider roles below Super Administrator, and non-person service credentials. This section covers all three, because element 3 of the FedRAMP secure-configuration rule asks the same four questions of privileged accounts that the previous section answers for top-level ones.
Accessing a scoped administrator account. There is no separate console URL, local password or bypass: a scoped administrator signs in exactly as any user (two-factor by policy, or your own identity provider's factor if you federate) and the administration console appears only if, on every request, the service finds the signed-in identity in a `Customer Admins` group of your organization; the check is made server-side against the identity provider, not from a claim in the session. Provider staff cannot reach your console through this lane: a provider-domain identity is never treated as a scoped administrator, and the provider's own in-application administrative lane requires provider identity *and* verified provider-organization membership (see the Administrative access section for the current state of that lane). Recommended posture: the same as for top-level accounts — named individuals, phishing-resistant authenticator, no shared mailboxes.
Configuring privileged rights. Rights are granted by group membership, never by editing a user. Seven *administrative* permissions exist and each is a separate group your scoped administrators can be placed in: Manage users (create, suspend, reactivate), Manage permission groups (grant and revoke these same administrative permissions), View activity log, Export activity log (CSV/JSON), Manage API access clients (create and revoke read-only audit API clients for SIEM pull), Reset authentication (reset a user's credentials where the identity provider allows it), and Manage deactivation dates (set user and group access expiration). Seven *capability* permissions govern what product functions a user may use — AI chat, corpus search, document generation, file management, tracking and alerts, workspace sharing, advanced research — and are set per user group. Recommended posture: put Manage permission groups, Reset authentication and Manage API access clients in the hands of the fewest people (they are the three that can create further reach: new administrators, account takeover of a user, and a standing non-interactive credential respectively), and grant capability permissions per user group rather than to everyone.
Operating them. Every administrative action taken through the console — user creation, suspension, reactivation, permission change, group membership change, credential reset, API-client creation or revocation, activity export — is written to an administrative audit trail with the acting identity, the target and the timestamp *before* the change is applied, so a failed audit write blocks the action rather than losing the record. Your scoped administrators with View activity log can read administrative, authentication, session, prompt and user events for your organization; with Export activity log they can pull them; with Manage API access clients they can hand a read-only audit feed to your SIEM. A permission check happens on each request, so a right removed mid-session stops working at the next call. Recommended posture: review the activity log for administrative events on the cadence you choose for administrator review, and treat any API access client you did not create as a finding.
Decommissioning them. Removing a user from a `Customer Admins`, `Permission - …` or `User Group - …` group withdraws the corresponding right on the next authorization check, without waiting for sign-out. Deactivation dates let you set an expiry on a user or on a whole group in advance, so temporary rights end without a manual step; use them for contractors, rotations and pilots. API access clients are revoked individually and the revocation is audited. If you federate, deprovisioning at your identity provider is authoritative and removes every right here. Recommended posture: expire before you delete — set the deactivation date, confirm the right is gone from the activity log, then remove the account — and re-check group membership after any bulk directory change, because membership, not job title, is what grants access.
Settings only privileged accounts can operate, and what they mean. (i) *Administrative permission-group membership* — the setting that manufactures more administrators; a change here should be rare and reviewed. (ii) *Capability permissions per user group* — these decide which product functions (including file management and workspace sharing) an identity can exercise, so they bound what content a compromised user account could reach or move. (iii) *Reset authentication* — resets a user's credentials; it is the takeover-capable action in the console and is audited as such. (iv) *API access clients* — each one is a standing, non-interactive, read-only credential to your audit data; creation and revocation are audited, and the credential is scoped to your organization's events only. (v) *Deactivation dates* — the only time-based right in the console; a cleared date silently removes an expiry, so treat clearing one as a grant. (vi) *Activity export* — moves audit data out of the boundary; it is a permission of its own for that reason. Every one of these is readable through the security-settings export described under Settings API, so your current state can be compared with this guide's recommended defaults without asking the provider.
The provider's privileged accounts, stated so you can judge them. Cloud side: below the single `AdministratorAccess` permission set described above, two permission sets (`Engineer-Security`, `Engineer-Standard`, 8-hour sessions) carry narrower rights and no administrative authority over the identity provider; all human cloud access is by federated, time-bounded session — the provider's own daily control measurement records zero standing-privilege principals and one non-person IAM user (a corpus transfer service identity with no privilege grants). Identity-provider side: one delegated role below Super Administrator, scoped to a single named group; two custom-scoped administrator roles held by federation service identities. Service identities: the authenticated web-scanner account is password-only by design and is confined by policy to the scanner's fixed egress addresses and to a one-member group that no human may join; automation credentials are non-interactive and hold no console password. In-application: provider full-administrator access requires provider identity and verified membership of the provider's employee group, enforced in code with a regression test. Intended state, stated deliberately: no standing provider-side full-administrator account exists in the government tenant; the in-application provider full-administrator lane is held by no one, and provider administrative access is break-glass only, recorded in the break-glass register — provider tenant administration is performed through the identity provider's administrator roles described above, not through the application.
How to check these claims rather than trust them. The permission and capability set is enumerated in the application code and changes only by release; the provider's control measurement runs daily and records privileged-role session limits, standing-privilege principals and authenticator enrolment for every privileged identity. Your own tenant's privileged-account state — administrators, permission groups, upload grants, API clients, SIEM destinations — is exported and compared with this guide's recommended defaults by the security-settings endpoint (see Settings API). Request the current administrative-account inventory and the latest measurement through the FedRAMP Security Inbox listed in the Vulnerability Disclosure section. Where a statement in this section is a commitment rather than a measurement it is named as such.
What this section does not claim. (a) It does not claim a session-cache lifetime for scoped access: administrator membership is resolved on each request, so "on the next authorization check" is the accurate phrase, not "within N minutes". (b) It does not claim that the provider's internal control-panel API routes are gated by the organization-membership check: at the time of this revision those routes still carry provider-email-domain predicates in code, and whether they are reachable on the government deployment is an open engineering question with an answer due 2026-09-25; if they are reachable they will be disclosed and dated here the way the scoped-access lane was. (c) It does not restate the provider Super Administrator count or the cloud-account root statement; those are in the Top-level administrative accounts section and are re-measured by the provider's daily control measurement.

Administrative access

Provider administrative surfaces are restricted to verified provider staff. The primary control requires both a provider identity AND verified provider-organization membership, checked server-side. A secondary lane that formerly granted on provider email domain alone was closed on 2026-08-21: both lanes now require verified provider-organization membership, checked server-side, and a regression test asserts the denial; the change has been in the served production image since no later than the 2026-09-04 build and was verified serving on 2026-09-11. On the government tenant the provider's employee group is not provisioned, so no account satisfies the in-application provider full-administrator check: no standing provider-side full-administrator account exists in the government tenant, and provider administrative access is break-glass only, recorded in the break-glass register. Agency users cannot reach provider administration through either lane.
New users have no access by default: a user without an organization assignment sees no tenant content. Membership is assigned at login against the agency's verified email domain or by explicit invite.
Agency-side sharing roles on work products are least-privilege (owner / editor / viewer), checked server-side per resource on every operation.

Sharing

Public and anonymous share links are disabled in code on this deployment. This is not a configuration setting: re-enabling would require a code change with a documented security disposition. There is no insecure state for an agency administrator to avoid.
The sanctioned sharing path is in-app grants to named users, teams, or groups: every reader authenticates, access stays inside the boundary, and all grant and revoke actions are recorded in a share audit log.

Sessions

Idle sessions terminate after 30 minutes (deployment-enforced; the session cookie lifetime is derived from the same value).
Sign-on re-authentication is required every 12 hours by identity-provider policy.

Data ingress

User file uploads are an in-scope feature of the assessed service, administratively gated on this deployment: the capability is default-deny per user and requires an explicit dual-consent administrative grant to enable — it is not open by default and not self-service. The feature appears in the service scope and Marketplace description (in scope for assessment) while remaining gated here. Additional content-handling controls apply under the federal data-handling policy.

Secure defaults

The shipped configuration is the recommended configuration: two-factor enforcement, no public links, no user uploads, a 30-minute idle timeout, deny-by-default access, and privileged rights granted only by group membership with a per-request check are the state of the deployment as provisioned — not settings an administrator must apply. The one recommended action for agency administrators is factor choice: enroll users in phishing-resistant authenticators (Okta Verify / passkeys) rather than email one-time-passcode.

Tracked items

The configuration exceptions this guide has disclosed since v1.1, each with its current state and a date (SCG-CSO-SDF). Measured 2026-09-12 against the application code, the identity provider and the provider's 2026-09-11 control measurement; record of measurement: scg-tracked-items-2026-09-12.md, sha256 9b42f80297e5680ec0dfde1a6b003110c0aadd2ff9a6eeb35d4a1c8811ff2440 (available through the FedRAMP Security Inbox on request).

Id	Item	State	Statement
SDF-1	Provider administrative lane granting on email domain alone	closed 2026-08-21	The secondary scoped-access lane that granted provider administrative access on email domain alone was brought under the same verified provider-organization membership check as the primary lane in code on 2026-08-21 (regression test asserts the denial), and has been in the served production image since no later than the 2026-09-04 build, verified serving 2026-09-11. Consequence on the government tenant: no account satisfies the in-application provider full-administrator check; provider administrative access is break-glass only (break-glass register). Evidence: scg-tracked-items-2026-09-12.md item 1, sha256 9b42f80297e5680ec0dfde1a6b003110c0aadd2ff9a6eeb35d4a1c8811ff2440
SDF-2	Email one-time-passcode retirement	open-dated 2026-12-15	Commitment: phishing-resistant multi-factor authentication for all users by 2026-12-15, then removal of the email factor as an authentication method (scoped by method and identity provider) after the enrollment campaign. Baseline 2026-09-11: the okta_email authenticator is active; 59 of 73 active users hold no phishing-resistant factor; 0 privileged users hold no phishing-resistant factor. Sequencing: trust the agency identity provider's MFA claim on both federations and prove a claim-less sign-in is refused (2026-10-15); every direct-identity-provider account enrolled in a phishing-resistant factor, break-glass first (2026-11-13); system-log proof that federated sign-ins no longer challenge email (2026-11-27); email removed as an authentication method and recorded in the next guide revision (2026-12-15). Evidence: scg-tracked-items-2026-09-12.md item 2, sha256 9b42f80297e5680ec0dfde1a6b003110c0aadd2ff9a6eeb35d4a1c8811ff2440

Recommended secure defaults (machine-readable)

Machine-readable recommended secure defaults (SCG-ENH-MRG / SCG-ENH-CMP). Each entry names one security setting by a stable id, the recommended value, and how it is enforced. comparator 'equals' means a current value is compliant when it equals 'recommended'; 'review' means the guide states a posture but no single value is correct for every agency, so the current value is surfaced for the administrator to judge and no automatic verdict is given. The VulcanGov application exports a tenant's current values and compares them against this list at GET /api/admin/groups/{groupId}/security-settings (see settingsApi). Deployment-scope settings are identical for every tenant and are the shipped state; tenant-scope settings are the choices an agency administrator makes.

Setting id	Scope	Recommended	Comparator	Enforced by	Statement
`authentication.twoFactorEnforced`	deployment	true	equals	identity-provider sign-on policy (catch-all rule)	Two-factor authentication is enforced by policy for direct application sign-ins; it is not a per-user option. Agency-federated sign-ins carry the factor at the agency identity provider.
`authentication.reauthenticationHours`	deployment	12	equals	identity-provider sign-on policy	Sign-on re-authentication is required every 12 hours.
`authentication.phoneSmsFactorsDisabled`	deployment	true	equals	identity-provider authenticator policy	Phone and SMS factors are disabled deployment-wide.
`authentication.securityQuestionsDisabled`	deployment	true	equals	identity-provider authenticator policy	Security questions are disabled deployment-wide.
`authentication.hostedLoginOnly`	deployment	true	equals	application code (hosted-login gate: every embedded credential lane refuses unless explicitly enabled)	Sign-in is the hosted identity-provider flow only; no embedded password or email-code lane is accepted by the application.
`authentication.agencyFederation`	tenant	(review; see statement)	review	agency identity provider (configured by the provider on request)	If your agency federates, multi-factor enforcement moves upstream to your identity provider; keep it enforced there. The application does not measure identity-provider configuration; verify it at your IdP.
`sessions.idleTimeoutMinutes`	deployment	30	equals	application session cookie (SESSION_INACTIVITY_TIMEOUT_SECONDS; the cookie lifetime is derived from the same value)	Idle sessions terminate after 30 minutes.
`sharing.publicShareLinksDisabled`	deployment	true	equals	application code (hard-true predicate at the data-access choke points; not a configuration setting)	Public and anonymous share links are disabled. The sanctioned sharing path is in-app grants to named users, teams or groups.
`dataIngress.userFileUploadsMode`	deployment	"admin-gated"	equals	build-time deployment mode (JUSTINIAN_USER_FILE_UPLOADS_MODE)	User file uploads are default-deny per user and require an explicit dual-consent administrative grant; the capability is never open by default or self-service.
`dataIngress.publicFileUploadsEnabled`	deployment	false	equals	application code (hard-off; the anonymous portal has no identity to gate on)	No anonymous or public upload path exists.
`capabilities.disabled`	deployment	["cloud-files", "email", "web"]	equals	build-time capability floor (JUSTINIAN_DISABLED_CAPABILITIES)	General web access, mailbox integration and cloud-drive integrations are compiled out of the deployment for every user.
`web.managedWebSearchEnabled`	deployment	(review; see statement)	review	runtime transport variable for the in-boundary managed search provider	Web search, where enabled, is the narrow managed in-boundary lane only (curated index, no arbitrary URL retrieval). The value is reported so an agency can see whether the lane is on.
`web.managedWebFetchEnabled`	deployment	(review; see statement)	review	runtime transport variable for the co-located fetch sidecar	Single-page web fetch is enabled in production (2026-10-28) and goes through the provider-owned sidecar and fetcher with allowlist enforcement on both. The value is reported so an agency can see whether the lane is on; the per-chat Internet toggle and the account-level Web Fetch permission gate it.
`web.managedWebFetchAllowlist`	deployment	[".gov", ".mil"]	equals	bedrock-proxy sidecar and fetcher service allowlist (enforced outside the application process)	Managed web fetch retrieves U.S. government and military domains only.
`audit.adminAuditTrailEnabled`	deployment	true	equals	application code (every administrative grant, revoke and setting change writes an admin audit event with acting identity and timestamp)	Administrative actions are recorded in a durable audit trail available to the agency administrator and, on request, to assessors.
`tenant.administrators.count`	tenant	(review; see statement)	review	agency administrator (grant / revoke via the access API)	Keep the number of agency administrators to the smallest workable set; review the list on a fixed cadence and treat a dormant administrator as a candidate for removal.
`tenant.administrators.nonActiveWithRights`	tenant	0	equals	agency administrator (withdraw rights before disabling or deleting the account)	No suspended, deprovisioned or otherwise non-active account should still hold agency administrator rights.
`tenant.permissionModel.configured`	tenant	true	equals	provider provisioning of the per-tenant permission groups; agency administrator assigns membership	Use the permission-group model so each administrator holds only the permissions the job needs. When no permission groups exist for a tenant, every agency administrator implicitly holds every permission.
`tenant.fileUploadGrants.count`	tenant	(review; see statement)	review	agency administrator with manage_permissions (per-user grant) and the user's own settings toggle	Grant file uploads per named user only when the role needs it; the default is deny.
`tenant.contentExportEnabled`	tenant	false	equals	provider staff (CISO) only, per tenant, audit-logged	Exporting prompt and response text to an external SIEM is a CUI-export decision; the default is disabled and the audit feed carries metadata only.
`tenant.featureGates.disabled`	tenant	(review; see statement)	review	provider operations, per tenant, on the agency's request	Product features withheld from this tenant beyond the deployment floor. Reported so the agency can confirm the list matches what it asked for.
`tenant.siemDestinations.enabledCount`	tenant	(review; see statement)	review	agency administrator with manage_api_clients	SIEM push destinations receive only this tenant's audit events; review that each enabled destination is still wanted.
`tenant.apiClients.activeCount`	tenant	(review; see statement)	review	agency administrator with manage_api_clients	Audit-pull API clients are read-only and tenant-scoped; revoke clients no longer in use and prefer an expiry on every client.
`tenant.contractExpired`	tenant	(review; see statement)	review	provider staff	Whether the tenant is in the contract-expired state (users can sign in but see a deactivation overlay). Reported for completeness.

Settings API: export, compare, adjust

How to view, export, compare and adjust security settings programmatically (SCG-ENH-EXP, SCG-ENH-CMP, SCG-ENH-API). All routes are served by the VulcanGov application inside the FedRAMP boundary and require an authenticated VulcanGov session (hosted identity-provider sign-in with two-factor enforced) holding agency administrator rights for the group; provider administrators may read any group. A request for a group outside the caller's administrative scope is refused (HTTP 403). Every export is recorded in the admin audit trail.

Authentication. Browser session (the same session an agency administrator uses for the admin console). Token-authenticated API clients for these routes are a roadmap item; the read-only audit-pull clients (manage_api_clients) do not reach these routes.

View, export and compare

Method	Path	Purpose
GET	`/api/admin/groups/{groupId}/security-settings`	export (SCG-ENH-EXP) and comparison against these recommended defaults (SCG-ENH-CMP) application/json: exportedAt, groupId, group, scgVersion, settings (every setting in recommendedDefaults with its current value, scope, basis and source), recommended, comparison [{setting, current, recommended, comparator, matches}], members (ids only; add ?includeEmails=1 for addresses)

Adjust

Method	Path	Requires	Adjusts
PATCH	`/api/admin/users/{memberId}/access`	manage_permissions (rights and upload grant), manage_deactivation (expiry)	agency administrator rights, per-user upload grant, per-user access expiry, per-user permission-group membership
POST / DELETE	`/api/admin/groups/{groupId}/api-clients[/{clientId}]`	manage_api_clients	audit-pull API clients
POST / PATCH / DELETE	`/api/admin/groups/{groupId}/splunk-destinations[/{destinationId}]`	manage_api_clients	SIEM push destinations
PATCH	`/api/admin/groups/{groupId}/deactivation`	manage_deactivation	tenant-wide deactivation date
PUT	`/api/admin/groups/{groupId}/content-export`	provider staff (CISO) only	prompt/response content export to SIEM (tenant.contentExportEnabled)

Deployment-scope settings are code- or policy-enforced and identical for every tenant; they have no adjust path by design. Feature gates (tenant.featureGates.disabled) and agency identity-provider federation are changed by the provider on the agency's request through the FedRAMP Security Inbox.

Reference with request/response examples: justinian-govcloud repository, docs/gov-parity/admin-security-settings-api.md (agency customers may request a copy through the FedRAMP Security Inbox).

Roadmap

Token-authenticated (non-session) API clients for the security-settings view and adjust routes, extending the existing per-tenant API-client mechanism
Dormant-administrator detection in the comparison block (last sign-in against the agency's review period)

Change history

Version	Date	Note
1.4	2026-09-12	Adds the 'Privileged accounts' section — the Recommended third element of SCG-CSO-RSC: how agency scoped-administrator and permission-bearing accounts and the provider's engineering and service identities are accessed, configured, operated and decommissioned, and which security-related settings only they can operate, derived from the deployed application code (seven administrative and seven capability permissions, per-request server-side membership check, audit-before-write trail, deactivation dates, API access clients) and the provider's daily control measurement, with an explicit list of what the section does not claim; the former 'Privileged accounts below top level' paragraph is superseded by it. Records the two tracked items disclosed since v1.1 with their state and dates (new trackedItems block): the provider administrative lane that granted on email domain alone was closed in code on 2026-08-21 and verified serving on 2026-09-11 — no standing provider-side full-administrator account exists in the government tenant and provider administrative access is break-glass only — and email one-time-passcode retirement is now a dated commitment (phishing-resistant MFA for all users by 2026-12-15; baseline 2026-09-11: 59 of 73 users without a phishing-resistant factor, 0 privileged). The Administrative access and Authentication sections state those closed and dated states. Adds the machine-readable recommendedDefaults block (24 settings with stable ids, recommended values and enforcement point) and the settingsApi section describing how to export a tenant's current security settings, compare them against these defaults, and adjust the adjustable ones (SCG-ENH-EXP, SCG-ENH-CMP, SCG-ENH-API; strengthens SCG-ENH-MRG). The three items previously listed as roadmap are delivered by the VulcanGov application's security-settings endpoint, which reads a vendored copy of this guide's recommendedDefaults; the two must be kept in sync and the application's CI checks the vendored copy against the published scg.json. This version is to be published when that endpoint is promoted to production, not before. Roadmap now carries the follow-on items only.
1.3	2026-08-25	Corrects the root-account statement in the top-level administrative accounts section before first publication. v1.2 described root multi-factor authentication as unenrolled and committed to enrolling it. That was wrong: AWS GovCloud (US) account roots have no console sign-in path and cannot hold access keys, so there is no root credential to enrol a factor on. The section now states the measured position — no root access key exists in any account, administration is entirely through federated identities — and explains the AccountMFAEnabled:0 reading an assessor will otherwise encounter without context. v1.2 was merged but never published, so no customer saw the incorrect commitment.
1.2	2026-08-25	Adds the 'Top-level administrative accounts' section required by SCG-CSO-RSC elements 1 and 2 — how top-level administrative accounts are accessed, configured, operated and decommissioned, and which security-related settings only they can operate, for both agency and provider administrators. Every provider-side figure was measured against the live identity provider and cloud control plane on 2026-08-25 rather than authored from documentation. Two open items are disclosed rather than omitted: AWS account root users do not yet have MFA enrolled (no root access keys exist in any account), and, at the time of drafting, provider Super Administrator identities remained on out-of-boundary mail domains. The latter was closed the same day: both such role assignments were removed and an unused administrator account on a retired domain was deprovisioned, leaving two Super Administrators, both in-boundary. The Authentication section's group-hygiene sentence was updated to match the live tenant after a non-production federation was deactivated.
1.1	2026-08-20	Authentication + data-ingress claims corrected to match the live tenant and code. 2FA enforcement stated with its two disclosed exceptions (agency-IdP federation, DAST service account) verified against the live Okta access policy — before/after evidence okta-signon-BEFORE-2026-08-20.json (sha 31f3c278) / okta-signon-AFTER-2026-08-20.json (sha 9e6127a2). Upload wording corrected from 'no admin permission' to 'admin-gated, default-deny, dual-consent'. Admin-surface scoped-access lane disclosed honestly as a tracked hardening item.
1.0	2026-08-18	Initial public release. Because the secure configuration is code-enforced rather than setting-based, the version history of this guide tracks the version history of the defaults.