# Enablement® Secure Configuration Guide (SCG)

| | |
|---|---|
| **Product** | Enablement® — workflow automation and secure content platform |
| **Provider** | Advent Business Company Inc. |
| **Certification target** | FedRAMP 20x — Class C |
| **Document version** | 1.0 |
| **Date** | 2026-08-07 |
| **Machine-readable companion** | `/20x/package` manifest |
| **Audience** | Federal agency administrators configuring an Enablement tenant (organization/"source") securely |
| **Support** | Support@adventbusiness.com |

> This guide implements the FedRAMP 20x **Secure Configuration Guide** ruleset
> (https://www.fedramp.gov/2026/reference/20x/c/secure-configuration-guide/).
> Section 12 maps every SCG rule ID to the material in this document.
> Statements that could not be grounded in Advent's published SOPs and user
> guides are explicitly marked **TODO — confirm with Advent** rather than
> asserted.

---

## 1. Scope and How to Use This Guide

This guide tells an agency administrator how to securely access, configure,
operate, and decommission the administrative surface of an Enablement tenant.
It covers:

1. Top-level administrative account access and protection (§2, §3)
2. Authentication policy options — password, TOTP MFA, third-factor OTP,
   passkeys, SSO, CAC/IPIV, and the security impact of each setting (§3, §4)
3. Session, lockout, and inactivity controls (§5)
4. Role-based access control (RBAC): groups, roles, auth items, privileges (§6)
5. User lifecycle: onboarding, review, deactivation, decommissioning (§7)
6. System-use notification / policy acceptance at login (§8)
7. Audit-log access (§9)
8. File-security features: CUI/distribution markings, secured files and
   secured email (§10)
9. Recommended secure defaults checklist (§11)
10. SCG rule mapping (§12)
11. Securely configuring an app you build on the platform — PaaS layer (§14)

**Layering note — this guide is the *application/tenant* configuration surface.**
The underlying *host/OS* configuration baseline (CIS Ubuntu 24.04 hardening of the
EC2 hosts — CM-2/CM-6/CM-7, audit, PAM, sshd) is a separate, continuously-assessed
layer: Wazuh SCA evaluates every host against the CIS benchmark each cycle (feeding
KSI-CNA-IBP / KSI-MLA-EVC), and the as-built hardening, deviation register, and
full NIST-800-53 / CMMC-L2 control mapping live in **`enablement-deploy/HOST_CIS_HARDENING.md`**.
Together the two layers cover the CM configuration-management family end to end.

**How to obtain this guide (published, machine-readable, live).** This guide
and its companion 20x artifacts are published at stable Advent-controlled URLs:

| Artifact | URL | Format |
|---|---|---|
| **This Secure Configuration Guide** | `https://enablement.cc/ml/20x/scg` | `text/markdown` (machine-readable) |
| **FedRAMP Trust Center** (human landing page) | `https://enablement.cc/ml/20x/trust` | HTML |
| **CPO / certification package** (replaces the SSP) | `https://enablement.cc/ml/20x/package?src_id=1711` | JSON manifest |
| **Live KSI evidence API** (re-executable for validation) | `https://enablement.cc/ml/20x/ksi?src_id=1711` | JSON, authenticated |

The SCG is served directly as machine-readable markdown at the `/scg` URL and
is linked from the Trust Center and inside the `/package` manifest, satisfying
SCG-CSO-PUB (public) and SCG-CSO-AUP (how-to-obtain-and-use, listed in the
package). The KSI evidence API is authentication-gated (returns 401
unauthenticated) so an assessor re-runs it with credentials. This guide is also
provided to each agency at tenant provisioning.

**Source documents.** The factual basis for this guide is Advent's
customer-facing security documentation delivered as 3PAO evidence:

- *Enablement Administrator SOP for Web* (SOP # ADM-0010-20)
- *Multi-Factor Authentication (MFA) SOP* (v1.0)
- *Log-In User Guide* (v1.04)
- *Passkey User Guide* (v1.01)
- *User Management with RBAC SOP* (v1.01)

---

## 2. Top-Level Administrative Accounts

### 2.1 How the first administrative accounts are created

- The agency (client) provides Advent the initial list of users, groups, and
  user roles. Advent preconfigures the tenant ("Dashboard") with groups,
  roles, processes, and applications, and sets up the users provided by the
  client (Administrator SOP §1 Overview).
- Advent's Helpdesk creates new user accounts and assigns access rights based
  on role, at the request of the client. The user receives an email with a
  link to the system and a username and password from
  support@enablement.us; the username is the user's official email ID
  (Administrator SOP §6).
- The initial password is system-generated and encrypted; users are
  encouraged to change it periodically from the login page
  (Administrator SOP §6).
- After the first list of users is set up, **users and groups can be
  maintained by the client**, while the Helpdesk primarily maintains roles,
  processes, and applications (Helpdesk also retains authorization to manage
  users and groups) (Administrator SOP §1).

### 2.2 Securing top-level administrative access — required configuration

| Setting / action | Requirement | Security impact |
|---|---|---|
| Third-factor authentication for system administrators | **MUST be enabled.** "High-privileged users (system administrators) MUST enable third factor authentication" (MFA SOP). The Login User Guide labels the additional security code step "Must for System Admin". | An attacker who compromises an admin's password *and* TOTP device still cannot log in without access to the admin's registered email (or SMS/phone) channel. Disabling it removes the strongest protection on the tenant's most powerful accounts. |
| Organization-approved authenticator app | Admins must use organization-approved authenticator applications and keep authenticator devices secure and updated (MFA SOP, Security Guidelines). | Unapproved apps may sync secrets to unmanaged clouds; approved apps keep the TOTP seed within the agency's device-management boundary. |
| Dedicated email account for administrative functions | Recommended best practice (MFA SOP): use a dedicated email account for administrative functions, and maintain a current email address for OTP delivery. | Separates the admin's third-factor channel from a high-volume personal inbox, reducing phishing and takeover blast radius. |
| Report lost or compromised devices immediately | Required practice (MFA SOP). | A lost authenticator or passkey device is a live credential; prompt reporting enables passkey removal and account lock. |
| Admin scope limitation | Administrator privileges are only applicable to the groups to which the admin user has access; IT-Infrastructure privileges only to the machines and executables the user has access to (Administrator SOP §2.7). | Even "Administrator" is not global: scoping admin rights per group/machine contains the impact of a compromised admin account. |

### 2.3 Decommissioning administrative accounts

- Remove the user from a group, or select **Delete from all Groups**; if the
  user is present in only one group, removing them from it also deletes the
  user (Administrator SOP §2.6).
- Follow the lifecycle timelines in §7 (disable within 24 hours when no
  longer associated; notify within 8 hours for terminations/transfers).
- Remove the departing admin's registered passkeys via Passkey Management
  (§4.3) and change shared/group authenticators when members leave
  (User Management SOP §E.3).
- Media holding tenant data is sanitized prior to disposal, release out of
  organizational control, or reuse using techniques and procedures IAW
  NIST SP 800-88 §4, with sanitization actions reviewed, approved, tracked,
  documented, and verified (source: SSP Appendix A, MP-6).
- **Tenant-level decommissioning (entire organization).** Advent prod support
  runs the **"Decommission an Organization"** process (Support application):
  it lists all client organizations in a dropdown, and on selecting an
  organization code plus a typed confirmation it permanently deletes **every**
  row belonging to that organization across the platform databases
  (configuration, runtime, and tenant data schemas) and removes the
  organization's master record. The operation is transactional (all-or-nothing
  rollback) and refuses the protected platform organizations. Because the
  platform is zero-trust (§3.4) — encryption keys derive from each user's
  password-independent master seed and Advent never holds them — deleting the
  organization's key material (`ADVENT_PBLC_KY` / per-user AES-seed rows) is a
  **cryptographic erasure**: any residual ciphertext in object storage becomes
  permanently undecryptable. Residual S3 objects and the organization's BPMN
  diagram files are then lifecycle-purged. Media sanitization for the
  underlying storage follows MP-6 (NIST SP 800-88 §4), reviewed, approved,
  tracked, documented, and verified (SSP Appendix A, MP-6).

---

## 3. Authentication Policy Options (per organization)

Enablement is multi-organization ("source")-aware: users who belong to
multiple organizations select the organization at login (Login User Guide,
Step 2). Authentication policy is configured **per organization**.

### 3.1 Where to configure MFA

(MFA SOP, "Accessing MFA Configuration")

1. Log in to the platform (production: https://enablement.cc).
2. Use the search function in the top-right corner; search for
   **"multi factor"**.
3. Open **"Process Multi Factor Authentication"** under the
   **Configuration Items** folder.
4. Click the process to open the configuration form.

### 3.2 Settings and their security impact

| Setting | Options | Recommended secure value | Security impact |
|---|---|---|---|
| **Authenticator Provider** | Microsoft Authenticator, Google Authenticator, other supported providers (dropdown) | An organization-approved provider | Determines which TOTP app users enroll with at first login (QR-code scan, 6-digit codes). Choosing a managed, approved provider keeps second-factor seeds on managed devices. Selection criteria: organizational preference and device compatibility (MFA SOP). |
| **Third Factor Auth Mode** | Email-based One-Time Password (select "Email" from the dropdown); Login User Guide also documents SMS and phone-call verification as delivery flows | **Enabled — mandatory for system administrators** (MFA SOP; NIST compliance note) | Adds a third, out-of-band factor beyond password + TOTP. Time-sensitive code is dispatched automatically to the registered address. Turning it off for admins violates the platform's stated NIST-compliance requirement and materially weakens admin account protection. |
| **Two-factor (TOTP) authentication** | "Should be enabled" for all users (Login User Guide, Step 5) | Enabled for all users | First-time login displays a QR code; the user scans it with the authenticator app and verifies a 6-digit code. Without TOTP, a phished or reused password is sufficient to take over an account. |
| **Password policy** | Requirements **vary by organization**: minimum length (usually 8+ characters; Advent's password-creation guidance uses a 10-character minimum), lowercase, uppercase, numbers, special characters (Login User Guide, Step 4; Secure Password Creation Techniques) | Minimum 10 characters with all four character classes | Longer, mixed-class passwords resist guessing and cracking. The password gates account access (encryption keys derive from a separate password-independent master seed — §3.4), so password strength is the first line of account-takeover defense. The per-organization policy is administrator-configurable: "Enablement provide[s] a configuration capacit[y] to system administrators for the composition and complexity of allowable password format", with parameters for case sensitivity, number of characters, and minimum mix of upper-case, lower-case, numbers, and special characters (source: SSP Appendix A, IA-5(1); parameters IA-5(1)(a)/(h) are shared Advent-and-Customer assignments). |
| **Email domain allowlist** | Login rejects usernames whose email domain is not permitted: "Domain is not permitted" (Login User Guide, Step 1) | Allowlist only the agency's official domains | Prevents accounts outside the agency's domains from ever reaching the password prompt. The allowlist is a **central Advent-support-maintained list** (`ADVENT_DMN` table: blocked domains, permitted full domains, permitted domain suffixes), served by the platform to both the login form and the Administrator **Add User** form (both reject a non-permitted domain before the account is created). It is **not** a client-admin-editable setting — a client cannot widen its own allowlist; Advent prod support maintains it. See `TENANT_SECURITY_CONFIGURATION_GUI.md` §9. |
| **Passkey registration prompt** | After successful login users are prompted "Secure Your Account" with Register / Not Now / Never (Passkey User Guide, Step 8) | Encourage **Register** | See §4. Passkeys are phishing-resistant and cannot be guessed or stolen like passwords. |

### 3.3 What users experience (enforcement flow)

The login sequence enforces the policy in this order (Login User Guide,
Steps 1–8): email/domain check → organization selection → account-lock
check → password → TOTP code (first-time: QR enrollment) → additional
security code (email/SMS/phone; mandatory for system administrators) →
privacy-policy acceptance (first login or policy update) → session start.

### 3.4 Zero-trust password model — critical operational impact

(Verified against application code, 2026-07-10)

- The system uses zero-trust security: **encryption keys are never derived
  from, or recoverable by, anyone other than the user** — administrators
  cannot read or unlock a user's encrypted content.
- Key material derives from a password-independent master seed
  (`V_MASTER_SEED`), not from the password itself. As a result, **users can
  self-reset a forgotten password from the login page without losing any
  encrypted data**: Forgot Password → email one-time code (reCAPTCHA
  v3-gated request) → code verification → new password. The same
  data-preserving reset is available in-app (Settings → Reset Password).
- The only actions that destroy key material are **explicit, user-initiated
  security actions**: "Reset Secure Keys" (generates a new keypair,
  abandoning old encrypted content) and "Wipe Access" (revokes encryption
  keys and shares). Neither is part of a password reset.

**Security impact:** the "admin resets your password" support-desk takeover
path remains closed (reset requires control of the user's registered email
plus the one-time code), while a forgotten password is no longer a
data-loss event. Administrators should still direct users to the
self-service Forgot Password flow rather than attempting account
manipulation.

### 3.5 Pre-login bot and automation defense

(Verified against application code, 2026-07-10)

Before the credential form is displayed, the login page runs a device
risk assessment; the form is withheld until the check passes:

- A **visitor ID** is generated with browser fingerprinting
  (FingerprintJS) and cached securely; the same ID is later bound into
  authentication and passkey-registration calls for per-device tracking.
- A **risk score** is computed from bot/emulation signals: timezone vs.
  IP-geolocation mismatch, software GPU rendering (headless browsers),
  abnormal screen resolution, touch-on-desktop spoofing,
  blocked/uniform canvas fingerprint, missing audio fingerprint, sparse
  font set, and blocked browser flavors.
- Scoring weights and the blocking threshold are **per-tenant
  configuration** (default block score 50, served by the
  `GetVisitorRiskScore` configuration); a score at or above the threshold
  blocks login with a risk-verification message.
- The **Forgot Password** flow is additionally gated by Google
  **reCAPTCHA v3** before an OTP is issued, throttling automated
  reset-code harvesting.
- Fail-open design: if the risk service is unreachable or times out
  (5 s), the login form is shown — availability is preferred over a
  hard-closed login for an infrastructure fault.

**Security impact:** headless/bot traffic is filtered before it can
exercise the authentication endpoints, and the risk threshold is tunable
per tenant when an agency wants stricter automation blocking.

### 3.6 Enablement PDNS Agent (Protective DNS / assessment lockdown)

(PDNS_AGENT.md)

A lightweight endpoint agent (Go, runs as an OS service) provides
protective DNS and assessment-mode network lockdown on user machines:

- **Local DNS proxy** on the device enforcing domain blocklists and
  allowlists; non-blocked queries forward to Quad9 (`9.9.9.9`) or a DoH
  endpoint.
- **Exam/assessment lockdown**: Mode A (strict — device network locked to
  permitted domains only, RFC1918 blocked) and Mode B (limited), switched
  by the application over a localhost control API.
- **Downloads for both desktop platforms**, offered in-app at login via an
  OS-detecting banner when the agent is required but absent:
  - **macOS**: `EnablementAgent-macos.pkg` — installs a launchd daemon
    (`sudo installer -pkg EnablementAgent-macos.pkg -target /`).
  - **Windows**: `EnablementAgent-windows.zip` — `pdns-agent.exe`
    (x64 and arm64 included) installs as a Windows Service
    (`pdns-agent.exe --install`, run as Administrator).
- The app detects the agent via localhost health endpoints
  (`127.0.0.1:49223` HTTP / `:49224` HTTPS, self-signed TLS generated at
  first run) and polls until the agent responds after download.
- Availability is policy/environment-gated per deployment.

**Security impact:** brings DNS-layer egress control and
assessment-integrity lockdown to the endpoint itself, complementing the
platform's server-side controls; administrators should distribute the
platform-appropriate installer during onboarding where PDNS enforcement
is part of the agency's policy.

---

## 4. Passkeys (Phishing-Resistant Authentication)

(Passkey User Guide)

### 4.1 What passkeys provide

- Passkeys use the device's built-in security: Touch ID (fingerprint),
  Face ID, Windows Hello (fingerprint/face/PIN), or external security keys.
- Biometric data stays encrypted on the user's device — never stored on
  Advent's servers.
- Each device gets its own passkey; passkeys cannot be guessed, stolen, or
  phished like passwords; only the enrolled user's biometric unlocks them.

### 4.2 Enrollment and use

- A user must first log in with password (+ MFA per policy). After
  successful login, the "Secure Your Account" prompt offers passkey
  registration; the user chooses the authentication method (Touch ID /
  Security Key / Windows Hello) and completes the device biometric prompt
  (Passkey User Guide, Steps 8–10).
- Daily login: enter email, select source if applicable, click the passkey
  icon, use the biometric — no password typed (Quick Login Process).
- Additional devices: log in on the new device with email + password and
  accept the "Set up passkey on this device?" prompt.

### 4.3 Passkey lifecycle management

- Settings → **Passkey Management** (via the User icon) lets a user view
  registered devices, remove passkeys from specific devices, and check
  passkey status.
- **Lost device:** log in from another device with email + password, remove
  the lost device's passkey in passkey settings, and contact the
  administrator for additional security measures.
- **Password-change interaction** (verified against application code,
  2026-07-10): password changes and password resets **do not affect
  passkeys** — passkey credentials bind to the password-independent master
  seed, so they remain valid after any password update, regardless of how
  the user logged in.
- **Explicit revocation:** passkey removal happens only through the
  dedicated **Revoke Passkey** dialog (User menu → Revoke Passkey), which
  supports revoking a single device, a specific passkey, or **all devices
  at once**.

  **Security impact:** users who suspect compromise should run "Revoke all
  passkeys" from the Revoke Passkey dialog *and* change their password —
  the password change alone no longer clears passkey credentials, so the
  explicit revocation step is the compromise-response control.
- Hygiene: set up passkeys only on trusted personal/managed devices, keep
  the password as backup access, remove passkeys from devices no longer
  used, and report unauthorized access (Security Best Practices).

---

## 5. Session, Lockout, and Inactivity Controls

| Control | Behavior / required value | Source | Security impact |
|---|---|---|---|
| Failed-login lockout | Each incorrect password increases the failed-attempt count; after too many failed attempts the account may be temporarily locked. Locks are either **time-based** ("Account locked until [time]") or **admin locks** ("Contact system administrator"). | Login User Guide, Steps 3–4; Troubleshooting | Throttles online password-guessing. Time-based locks self-heal; admin locks require human review before access resumes. |
| Logon attempt limits and lock/delay | Enforce logon attempt limits and automated lock or delay; apply mobile device wipe after consecutive failures as defined by policy. | User Management SOP §G.2 | Extends brute-force protection to mobile access (AC-7, AC-7(2)). |
| Session inactivity | Require logout if inactivity is expected to exceed **15 minutes** (shorter than AC-12 where appropriate). | User Management SOP §G.1 | Limits the window in which an unattended session can be hijacked. Users are also instructed to log out when finished and never leave a logged-in computer unattended (Login User Guide, Security Tips). |
| Failed-attempt lock parameters (defined values) | The failed-attempt limit and window are enforced per the organization's access-control policy; on exceeding the limit the account is locked for a **minimum of three (3) hours or until unlocked by an administrator**, or the next logon prompt is delayed. Parameters are shared Advent-and-Customer assignments. Evidence shows both admin unlock and timed auto-unlock in the GUI. | SSP Appendix A, AC-7(a)/(b); evidence screenshots "AC-7.a Admin Unlocking User.png", "AC-7.a Auto unlock message for humans.png", "AC-2 (3) Password Brute Force Lockout.png" | Bounds online guessing; ≥3-hour lock makes distributed slow-guessing impractical while admin unlock preserves help-desk recovery. |
| Session lock (defined value) | Session lock initiates after **fifteen (15) minutes of inactivity** (or on user request) and is retained until the user re-authenticates; the lock conceals previously visible content (pattern-hiding). Automatic session termination occurs on organization-defined events (inactivity, logoff, anomalous behavior). | SSP Appendix A, AC-11 / AC-11(1) / AC-12; evidence screenshots "AC-11.a Session Timeout on No Activity.png", "AC-2(5) Auto Screen lock on activity.png", "No Activity Timeout Alert With blured App.png" | The 15-minute lock plus blurred/pattern-hidden display limits both hijack and shoulder-surfing exposure of an unattended session. |
| Session/lockout parameter configuration screen | **Configuration Items → Inactivity Policy** is the tenant screen for these values: `Max_Login_Attempts` (failed-attempt threshold), `Require_Admin_to_Unlock`, `Inactivity_Minutes_Timeout` (AC-12 logout), `Idle_Minutes_Screen_Lock` (AC-11 lock), `Inactivity_Lockout_Threshold_Days` (AC-2(3) auto-disable). All persist to `BPM_CFG.ADVENT_SRC_PRPT` for the organization. Full field↔column map: `TENANT_SECURITY_CONFIGURATION_GUI.md` §5. | Configuration Items → Inactivity Policy | Per-organization tunable; enforced values in SSP Appendix A. |

---

## 6. Role-Based Access Control (RBAC)

(Administrator SOP; User Management SOP)

### 6.1 Model

- **User** — an individual authorized to log in (username = official email).
- **Group** — a logical collection of users. Out-of-box groups: Help Desk,
  DevSecOps, Software Developer, IT Infrastructure, Business Analyst, Group
  Administrator, Role Administrator. Groups are visible only to users with a
  group role.
- **Role** — a logical collection of Items granted to group(s)
  (e.g., Help Desk Analyst, DevSecOps Role). The system ships preconfigured
  with some roles.
- **Item (auth item)** — an entity on which access is enforced: Process,
  Task (Service), Executable, Platform, Machine, Artifact. All auth items
  are pre-existing; an administrator can only attach them to roles, not
  create new item types.
- **Privileges** — CURDE: Create, Update, Read, Delete, Execute, set per
  item per role.
- The agency's Customer Administrator maintains a catalog of roles
  (privileged, non-privileged, or no-logical-access) with authorized
  privileges and functions (e.g., Administrator, Help Desk, Auditor, End
  User) (User Management SOP §3).

### 6.2 Configuration procedures (Administrator profile)

- **Groups:** filter/search; add one (name, optional description, start and
  end date) or bulk-add via downloaded template upload; edit; delete
  (Administrator SOP §1).
- **Users:** add to a group directly or in bulk via the Users template;
  drag-and-drop to copy a user into another group; remove from one group or
  delete from all groups (Administrator SOP §2).
- **Roles:** add singly or via template; edit; delete (Administrator SOP §3).
- **Auth items → roles:** select item type (Process / Service / Executable /
  Machine / Platform / Artifact), the role, and either "all" or a specific
  item; then double-click the CURDE icons to toggle privileges (gray =
  disabled) (Administrator SOP §4).
- **Role ↔ Group association:** link icon on the Role pane (assign a role to
  groups) or the Group pane (assign a group to roles); check/uncheck and
  submit (Administrator SOP §5).
- **Per-user permission panels:** Workflow rights (Execute, Approve,
  Dashboard, Exception Resolution, Schedule Management, Download BPMN
  Design, Process Design, Application, Monitoring, **Audit**), Administrator
  rights (Manage Groups, User Management, Membership Management, Role
  Management, Manage Auth Item, Associate Roles, Organizational
  Logo/layout), and IT-Infrastructure rights (Platform, Executable, Machine,
  Connection, Deployment, Install Management) (Administrator SOP §2.7).

### 6.3 Secure-by-default behaviors and their impact

| Behavior | Security impact |
|---|---|
| **A new user has only the 'Execute' privilege by default** (Administrator SOP §2.3, Tips). | Least privilege on day one: a newly onboarded user can run processes they are given but cannot create, modify, or delete anything until an administrator explicitly grants more. |
| **Read privilege is auto-added and cannot be disabled** on an item attached to a role (Administrator SOP §4.3–4.8). | Prevents nonsensical "write-without-see" grants; an item attached to a role is always at least visible, so grants are auditable and predictable. |
| Workflow privileges apply **only to processes the user has access to**; Administrator privileges only to **groups the user can access**; IT-Infrastructure privileges only to **machines/executables the user can access** (Administrator SOP §2.7). | Privileges are scoped, not global — compromising one privileged user does not automatically expose the whole tenant. |
| Executables, Machines, Platforms need to be in roles **only for users who create/update/delete them** — not for users who merely execute processes (Administrator SOP §4.5–4.7). | Keeps infrastructure objects out of ordinary users' roles entirely, shrinking the attack surface for privilege misuse. |
| Artifact privileges are auto-granted to the artifact owner and the owner's group; role-based artifact grants are for special purposes **with the owner's approval** (Administrator SOP §4.8). | Data-owner consent is built into the sharing model. |
| Changing an auth item's CURDE privileges in one role auto-sets the same privileges in other roles (Administrator SOP §4). | **Caution:** a privilege change propagates across roles — review the effect on every role that carries the item before saving. |
| Separation of duties; restrict privileged accounts from non-security functions (User Management SOP §B.2). | Aligns with AC-5/AC-6 and CMMC AC.L2-3.1.6. |
| Shared/group accounts only when justified by business need, with documented rationale and compensating controls (User Management SOP §F). | Preserves individual accountability in the audit trail. |
| Federation: Enablement provides built-in IdAM and can federate with customer LDAP/Active Directory; where a customer IdP is used, maintain RBAC parity and least-privilege mappings (User Management SOP, Introduction; §J). | Prevents an external IdP group mapping from silently over-granting Enablement privileges. |

---

## 7. User Lifecycle (Onboarding → Review → Deactivation)

(User Management SOP; Administrator SOP)

### 7.1 Onboarding / provisioning (AC-2, AC-6)

1. **Precondition:** the individual signs an access agreement on or before
   access is granted; agreements are re-affirmed at least annually.
2. Create the account via the automated mechanism and role template (RBAC) —
   single add (Administrator SOP §2.3) or spreadsheet bulk upload: download
   the Users template, fill in email ID, description, and group, and upload
   it (User Management SOP, "Onboard Users").
3. The new user receives an email notification with **one-click access**
   (a link they click to get into the system) and is **advised to reset the
   password** (User Management SOP, "User Email Notifications").
4. Enforce least privilege at both the application layer (Enablement RBAC)
   and the cloud layer.
5. Log and audit all account lifecycle events (create/modify/disable/remove).

### 7.2 Ongoing operation

- **Privileged access:** administer privileged accounts under the role-based
  scheme; monitor assignments and changes; revoke when no longer
  appropriate (User Management SOP §B).
- **Reviews:** privileged accounts **monthly**; non-privileged accounts
  **every six months** (§E.2). Metric targets: 100% of privileged accounts
  reviewed in the last 30 days; 100% audit coverage of lifecycle events (§7
  Metrics & Triggers).
- **Notifications:** notify account managers within **24 hours** when
  accounts are no longer required; within **8 hours** for terminations,
  transfers, or need-to-know changes (§E.1). Align account actions with HR
  termination/transfer processes; change shared/group authenticators when
  members leave (§E.3).

### 7.3 Deactivation and removal

| Trigger | Required action | Source |
|---|---|---|
| Temporary / emergency account | Automatically disable **no later than 24 hours from last use** | User Management SOP §C |
| Account expired, user no longer associated, or policy violation | Disable within **24 hours** | §D |
| Inactivity | Disable beyond the organization-defined period — FedRAMP guidance **35 days** | §D |
| Terminated / transferred user | Mean time to disable target **≤ 8 hours**; "no longer required" ≤ 24 hours | §7 Metrics |
| Manual removal | Remove user from a group or "Delete from all Groups" (removal from the only group deletes the user) | Administrator SOP §2.6 |
| Exceptions (shared accounts, emergency access) | Document business justification, scope, duration, compensating controls; approval required before activation | §8 Exceptions |

**Security impact:** these timelines bound the lifetime of orphaned
credentials — the most common lateral-movement entry point — and the
monthly/semiannual reviews catch privilege creep.

The 35-day inactivity disable is **automated by the platform**: "Enablement
enforces auto-disable for inactivity per the access control policy" and
"Enablement can automatically disable inactive accounts in accordance with
their access control policy"; temporary/emergency accounts are likewise
auto-disabled (source: SSP Appendix A, AC-2(3) — FedRAMP assignment
thirty-five (35) days — and AC-2(2); evidence screenshots "AC-2 (3) Disable
Inactive Accounts.png", "AC-2 (2) Disable Temporary and Emergency
Accounts.png").

---

## 8. System-Use Notification / Policy Acceptance at Login

- On first login and whenever the policy is updated, the user must read the
  privacy-policy document, check "I accept", and click Continue before login
  proceeds; login is not enabled until the user accepts (Login User Guide,
  Step 7; Passkey User Guide, Step 1 and Step 7).

**Security impact:** guarantees every user has affirmatively acknowledged
the current terms of use before receiving a session; re-acceptance on
update means policy changes cannot be silently bypassed.

The login acceptance screen **is the AC-8 system-use notification and is
configurable per organization**: Enablement displays an
organization-defined system-use notification/banner before granting access
stating that users are accessing a U.S. Government information system, that
usage may be monitored/recorded/audited, that unauthorized use is
prohibited and subject to criminal and civil penalties, and that use
indicates consent to monitoring; the banner is retained on screen until the
user acknowledges and takes explicit action to log on (source: SSP
Appendix A, AC-8 — parameter AC-8(a) is a shared Advent-and-Customer
assignment). The deployed banner shows a "* WARNING *" / "FOR OFFICIAL USE
ONLY" / "Monitoring & No Expectation of Privacy" statement with a mandatory
"I have read and agreed" checkbox before Continue (source: evidence
screenshots "AC-8.b System Use Notification Configuration & Banner
Display.png", "AC-8.b System Use Notification Configuration & Banner
Accepted.png", "AC-2.g Configurable Privacy Policy Per Customer.png").

---

## 9. Audit-Log Access

- **Audit Access Right:** the Administrator grants the Workflow "Audit
  Access Right" per user (Administrator SOP §2.7). Grant it to auditors and
  ISSO staff; withhold it from general users.
- The RBAC role catalog explicitly anticipates an **Auditor** role
  (User Management SOP §3).
- **What is recorded** (MFA SOP, "Audit Trail" + User Management SOP §H):
  - All MFA configuration changes are logged and auditable.
  - Authentication attempts are recorded for compliance; **failed
    authentication attempts trigger security alerts**.
  - Account lifecycle events (create/modify/disable/remove) are
    automatically audited and alerted, integrated with CloudTrail/CloudWatch
    for notifications.
  - Regular review of MFA effectiveness is required.

**Security impact:** separating the *Audit Access Right* from operational
rights lets the agency give auditors read access to security events without
granting them any ability to change configuration — supporting separation
of duties.

**Audit viewer (GUI):** users granted the right see a **User Audit menu**
whose logs record the Action, Subject, and Data of user activity, with
search/filter; session auditing is applied per customer policy, and the
Audit Access right is enabled for an Auditor group by the Administrator
(source: evidence screenshots "AC-2.g User Audit Menu.png", "AC-2 (4) User
Audit Logs for Actions, Subject and Data.png", "AC-2.g User Session Audit
Per Customer Policy.png", "AC-2.g Enable Audit Access Auditor Group.png").
The platform provides on-demand audit reduction and report generation that
does not alter record content or time ordering, with processing/sort/search
on policy-defined fields (source: SSP Appendix A, AU-7 / AU-7(1)).

**Audit-record export and scheduled reporting.** The audit-trail results table
(the shared report-table component, read-only) carries built-in
**Manage-Column / Search / Sort / Export** controls; export formats are **XLS,
PDF, and PNG** (AUDIT_PROFILE.md §6B, AU-7). Beyond on-demand export, the
platform runs a **scheduled "User Audit Report"** — a five-service BPMN process
(Audit application) that scans user activity for anomalies, builds an XLSX
report, and emails it to the tenant's auditor group. Cadence is per-tenant
(`ADVENT_SRC_PRPT.Audit_Cadence` = Daily | Weekly | off) via a Quartz trigger;
each run — even a zero-anomaly one — writes a dated `ADVENT_AUDIT_LOGS` row as
AU-6 review evidence, and anomalous users are auto-flagged and surfaced in the
Audit "Flagged" filter. The anomaly report scores each user on weighted flags
(geo-distance, off-hours/weekend logins, failed logins, privilege changes,
dormant reactivation, new IP, rapid actions). Any auditor can also run it
on-demand (Audit → User Audit Report → Run). Full detail: AUDIT_PROFILE.md
§6B/§7B. Process monitoring has a parallel anomaly capability
(`GetUserExecutionPattern`) plus a kill-switch (`StopProcessInstance` /
`StopUserProcessing`); its per-instance/chart views are on-screen only (no
export/schedule documented) — see MONITOR_PROFILE.md §11.

---

## 10. File-Security Features (CUI / Distribution Markings, Secured Files & Email)

Secured content is integrated with the identity model of §3–§4: user
accounts may be **auto-created when a person receives secured content**
("No Sign Up" — Login User Guide, cover page; evidence screenshots
"Register User for File Share.png", "Register new user with compliance
check on sensitive CUI file share.png"), and the zero-trust encryption
model (§3.4) applies — the user's password keys their encrypted data, and
shared data remains accessible to recipients even if the owner loses their
password.

### 10.1 CUI and distribution-statement markings

- **CUI categories:** at upload/marking time the user selects CUI
  categories from the full CUI Registry list in a searchable "Select CUI
  Categories" dialog (search by abbreviation, keyword, or description);
  categories can also be added manually, on desktop and mobile (source:
  evidence screenshots "CUI Categories Selection.png", "Add CUI Categories
  Manually.png", "Select CUI Manaully Mobile.png").
- **Limited-dissemination / distribution codes:** a searchable "Select
  Distribution Codes" dialog offers the CUI limited-dissemination controls
  (FED ONLY, FEDCON, NOCON, DL ONLY, RELIDO, NOFORN, REL TO USA [LIST],
  DISPLAY ONLY, ATTORNEY-CLIENT, …) with full descriptions (source:
  evidence screenshots "distrubition marking.png", "Select Distribution
  Codes Manually Mobile.png").
- **Banner format:** markings are applied as a banner of the form
  `CUI // <CATEGORY1, CATEGORY2, …> // <DISTRIBUTION>` (source:
  COMPLIANCE_MARKING_PARSING_DESIGN.md, `getCuiBanner()`).
- **Marking application to files:** Excel workbooks receive the CUI banner
  in the **top row of each sheet plus a "CUI Designation" cover tab**;
  document previews carry a generated CUI designation block ("Controlled
  by", category list, "Limited Dissemination Control", POC) (source:
  evidence screenshots "Excel Marking On Top Row.png", "Excel Marking Cover
  Tab.png", "Watermarked Readonly No Download Preview File.png").
- **Duplicate-marking avoidance:** files that already carry compliance
  markings are auto-detected; the banner is parsed to pre-populate the
  compliance tag, categories, and distribution fields for user review, and
  the sensitive-word scan is skipped, avoiding double marking (source:
  COMPLIANCE_MARKING_PARSING_DESIGN.md; evidence screenshot "Auto Detecion
  of Premarked Dos to avoid  Duplicate Marking.png").
- **Content-based detection:** upload scanning includes sensitive-word and
  restrictive-language checks with text extraction (e.g., ITAR
  notification), with alerts when auto-detection fails so the user marks
  manually (source: evidence screenshots "Restricted Language Detection
  with Text Extraction.png", "CUI ITAR Notification.png", "Alert for Failed
  Auto Detection of Complaince Tab.png").

### 10.2 Secured Files — encryption and sharing

- **Encryption defaults (end-to-end, client-side):** each file is encrypted
  in the browser with a fresh **AES-256-GCM** content key (96-bit IV,
  AAD-bound context); the content key is wrapped **per recipient** with
  **RSA-OAEP-3072 (SHA-256)**; a signed JSON manifest (**ECDSA P-256** with
  SHA-256) binds the artifact context, plaintext/ciphertext hashes, and
  recipient list; ciphertext is stored in S3 (SSE-KMS beneath) (source:
  SECURED_FILES_ENCRYPTION_ARCHITECTURE.md — KB02 format; SSP Appendix Q,
  DIT/Other tables rows "Client-side payload encryption",
  "Per-recipient CEK wrapping", "Client-side manifest signature").
- **Sharing and folder sharing:** files and folders are shared per
  recipient via the Share dialogs (recipient-wrapped keys); folder share
  and delete are first-class operations (source: evidence screenshots
  "Share File Dialog Box Part 1.png", "Share Folder Dialog Box Part
  1/2.png", "Folder Share and Delete Feature.png";
  FOLDER_SHARE_IMPLEMENTATION.md).
- **Per-upload security settings:** the upload dialog captures a Security
  Classification (classification level + sensitivity level), organizational
  context (department/project), per-file settings, and optional alerts
  before upload proceeds (source: evidence screenshots "UploadFiles with
  Security Setting Part1–4.png").
- **Shared-file expiration:** shared access is time-boxed by the
  per-customer **Shared File Expiry** setting (days) (source: evidence
  screenshot "File Scan and Expiry Policy Per Customer.png").
- **Pre-expiry share revocation (un-share).** The file owner revokes access
  before expiry from the share-management dialogs — file-level (share
  recipient card → revoke) or folder-level (**Manage Shares** →
  individual revoke, or bulk "Revoke Selected" with an optional cascade that
  also revokes downstream re-shares). Revocation is **immediate and
  synchronous** (SP `RevokeShare`, optional cascade via the parent-share
  chain; `BulkUpdateShares` for batches), writing `REVOKED_AT`/`REVOKED_BY`
  and an audit row. **Effect:** the revoked recipient can no longer resolve
  the file's storage locations or obtain presigned URLs, so they can no longer
  list, view, or download it — DB revocation is the enforcement point (the
  recipient's wrapped key becomes inert). **Already-downloaded copies:** a
  plaintext copy the recipient saved *before* revocation is outside the
  platform's control and is not recalled — this is why sensitive shares should
  use the non-download access levels (metadata / watermark / read-only preview,
  §10.4) rather than full download. Source: SECURED_FILES_ENCRYPTION_ARCHITECTURE.md
  §6/§10/§15, FOLDER_SHARE_IMPLEMENTATION.md §13.

### 10.3 Secured Email

- Enablement includes a built-in secured email client (Inbox / Sent /
  Drafts / Trash, plus user-created custom subfolders); messages display a
  **CUI Designation Indicator block** (Controlled by, Type, CUI Category,
  Distribution/Dissemination Controls, POC) and carry an **expiration**
  (e.g., "Expires in 14 days") (source: evidence screenshots "Secured
  Eamil/Secured Email.png", "Email Subfolders.png";
  EMAIL_CUSTOM_FOLDER_IMPLEMENTATION.md).
- Email bodies and attachments use the same client-side KB02 encryption
  path as Secured Files (per-recipient wrapped keys; "secure email
  ciphertext, per-recipient bundles" stored encrypted in S3) (source:
  SECURED_FILES_ENCRYPTION_ARCHITECTURE.md; SSP Appendix Q, DAR row 1).
- External recipients are provisioned through the auto-created-account
  ("No Sign Up") flow above, with a compliance check applied when sensitive
  CUI files are shared to a new user (source: evidence screenshot "Register
  new user with compliance check on sensitive CUI file share.png").
- **Auto-created recipient accounts — default privileges and lifetime.** When
  secured content is shared to a person with no account, the account is
  provisioned through `POST /rest/User/AddAndSendEmail` →
  `UserProvisioningService` (the same authoritative path as all user creation).
  Defaults: the account is placed in the base **`Enablement`** group with status
  **ACTIVE**, marked unpaid, and stamped with a **landing surface**
  (`showprofile = securedfile | securedemail`) so it opens only to the Secured
  Files or Secured Email screen — it does **not** receive workflow, designer, or
  administrator privileges (least privilege; general RBAC still applies, and a
  new recipient triggers the `NEW_USER_REVIEW` compliance gate before any CUI
  share completes). **Lifetime:** the *account* itself carries no fixed expiry,
  but it is subject to the same lifecycle controls as any user — AC-2(3)
  inactivity auto-disable (FedRAMP 35 days) and the tenant's
  `Inactivity_Lockout_Threshold_Days`. The "Expires in N days" the recipient
  sees is the **share/message expiry** (per-share `EXPY_DT_TM`, bounded by the
  tenant `Shared_File_Expiry`), not an account expiry. Source:
  USER_CREATION_API_WITH_VALIDATION_FIELDS.md, FOLDER_SHARE_IMPLEMENTATION.md
  ("Auto-Provisioning New Recipients"), SECURED_FILES_ENCRYPTION_ARCHITECTURE.md §7/§11.
- **Is an explicit account expiry required for 20x? No — the existing inactivity
  auto-disable satisfies the control.** FedRAMP 20x inherits AC-2 account
  management; the operative requirement for accounts that stop being used is
  **AC-2(3) disable-inactive-accounts (35 days)**, which the platform already
  applies to *every* account, auto-created recipients included (§7.3). So a
  guest who receives one file and never returns is auto-disabled at 35 days —
  the account does not linger indefinitely, which is what the control asks for.
  A fixed "expire in N days" on recipient accounts is therefore **optional
  hardening, not a compliance gap**; if desired it would tighten the AC-2 story
  for a 3PAO (treat auto-created recipients like temporary accounts under
  AC-2(2), ≤24 h short window), but it is not needed to assert compliance. The
  *share/message* itself already expires independently (per-share `EXPY_DT_TM`,
  bounded by `Shared_File_Expiry`), so access to the content is time-boxed even
  while the account remains active.

### 10.4 Watermarking and read-only viewing

- Shared files can be granted a **WATERMARK access option**: the share
  dialog provides a watermark text input and color picker; watermarking is
  applied server-side for Office formats (DOCX, XLSX, PPTX) and to PDFs,
  including secured-email attachments (source:
  OFFICE_WATERMARKING_ANGULAR_INTEGRATION_GUIDE.md).
- Watermarked delivery is a **read-only, no-download preview** — the
  recipient views a diagonally watermarked rendition (e.g., "CONFIDENTIAL")
  with the CUI designation block, without receiving the original file
  (source: evidence screenshot "Watermarked Readonly No Download Preview
  File.png").

### 10.5 Upload malware scanning and scan policy

- Uploads pass through malware scanning (ClamAV `clamd` + REST API);
  infected files are removed while the remaining upload continues, with a
  visible scan progress bar and pending-scan warnings (source: SSP §8.2
  Table 8.1 "ClamAV (docker and REST API)"; evidence screenshots
  "Infected:Virus File Removal and Upload Continuation.png", "Security Scan
  Progress Bar.png", "Pnding Security Scan Warning.png").
- Scanning behavior is governed by the per-customer **File Scan and Expiry
  Policy** Configuration Item: Scan File Before Upload (Yes/No), Scan File
  Before Download (Yes/No), Check Sensitive Words (Yes/No), Check
  Restrictive Language (Yes/No), Shared File Expiry (days). Set all scan
  options to **Yes** (source: evidence screenshot "File Scan and Expiry
  Policy Per Customer.png").
- Only authorized users may override scan settings at upload, and a user
  accepting the risk of skipping a language scan must do so explicitly
  (source: evidence screenshots "Authorised User Access Rights to Override
  Scan Settings.png", "Upload Files with scan overwrites for authorized
  Users.png", "User accepting Risk of no language scan.png").

---

## 11. Recommended Secure Defaults — Checklist

Configure every new Enablement organization to this baseline. Items marked
(default) already ship in this state.

| # | Setting | Secure value |
|---|---|---|
| 1 | TOTP two-factor authentication | Enabled for **all** users |
| 2 | Third Factor Auth Mode | **Email OTP enabled; mandatory for system administrators** |
| 3 | Authenticator Provider | Organization-approved app (Microsoft/Google/other approved) |
| 4 | Password policy | Minimum 10 characters; upper + lower + number + special |
| 5 | Email domain allowlist | Agency domains only |
| 6 | Passkeys | Registration encouraged on trusted/managed devices; Passkey Management reviewed when devices are lost or retired |
| 7 | New-user privileges | Execute-only (default) — grant CURDE additions per role review |
| 8 | Privileged roles | Scoped to required groups/machines only (default scoping); separation of duties enforced |
| 9 | Shared accounts | None, absent documented justification + approval |
| 10 | Temporary/emergency accounts | Auto-disable ≤ 24 h from last use |
| 11 | Inactivity disable | 35 days (or stricter) |
| 12 | Session behavior | Logout at ≤ 15 min expected inactivity; lockout on repeated failed logins |
| 13 | Account reviews | Privileged monthly; non-privileged semiannually |
| 14 | Audit Access Right | Granted to auditor/ISSO users only |
| 15 | Policy acceptance at login | Enabled (default — login is blocked until acceptance) |

Rows 10–12 are platform-enforced, not merely procedural: temporary/
emergency and inactive accounts are auto-disabled per AC-2(2)/(3), and the
15-minute session lock and ≥3-hour failed-attempt lock are enforced per
AC-11/AC-7 (source: SSP Appendix A; see §5, §7.3).

**Shipped defaults vs agency-configured (rows 1–5).** Every setting ships with
a default seeded at provisioning (the `ADVENT_SRC_PRPT` column default); the
agency administrator then hardens it via **Configuration Items** after handoff.
The shipped defaults are permissive baselines, so the §11 recommended values in
rows 1–5 are **agency-configured, not shipped-secure**:
row 1 (MFA) ships enabled-capable (`Show_MFS_Options=Yes`, provider Microsoft);
row 2 ships with `None` among the allowed third-factor modes (admins must set
Email OTP); row 3 defaults to Microsoft; **row 4 ships weaker than recommended**
(`Min_Length=6`, all class minimums `0`) and must be raised to 10 + four
classes; row 5 (domain allowlist) is Advent-support-controlled, not a tenant
default. What **is** secure-by-default as shipped: Execute-only new users
(§6.3), Read force-enabled, admin scoping, third-factor mandatory-for-admins
labeling, login-blocking policy acceptance, and the platform-enforced
AC-2(2)/(3)/AC-7/AC-11 controls (rows 10–12). Full default↔column table and
which Configuration Items process edits each: `TENANT_SECURITY_CONFIGURATION_GUI.md`
§3, §6.

---

## 12. How This Guide Meets Each SCG Rule

FedRAMP 20x Secure Configuration Guide ruleset — applicable to all providers
with FedRAMP Certifications (effective 2026-03-01).

### SCG-CSO-RSC — Recommended Secure Configuration (MUST)
*"Providers MUST create, maintain, and make available recommendations for
securely configuring their cloud services," including secure access,
configuration, operation, and decommissioning of top-level administrative
accounts, and explaining security-related settings and their implications.*

**How this guide meets it:** this document is that recommendation set. §2
covers secure access, operation, and decommissioning of top-level
administrative accounts; §3–§10 explain every security-related setting with
an explicit **security impact** statement (tables in §2.2, §3.2, §5, §6.3,
§7.3); §11 consolidates recommended values. Privileged (non-top-level)
account settings are covered by the same sections (SHOULD clause). One
decommissioning gap is flagged as TODO in §2.3.

### SCG-CSO-AUP — Use Instructions (MUST)
*"Providers MUST include instructions in the FedRAMP Certification Package
that explain how to obtain and use" the guide.*

**How this guide meets it:** §1 ("How to obtain this guide") states the
distribution channel (certification package + `/20x/package` machine-readable
companion + delivery at tenant provisioning) and §1's numbered scope list is
the usage map. Final package URL is a flagged TODO.

### SCG-CSO-PUB — Public Secure Configuration Guidance (SHOULD)
*"Providers SHOULD make the Secure Configuration Guide available publicly."*

**How this guide meets it:** published and live at
`https://enablement.cc/ml/20x/scg` (served as machine-readable markdown),
linked from the Trust Center (`/ml/20x/trust`) and the CPO package manifest
(`/ml/20x/package`). See §1 for the full URL table. **Met.**

### SCG-CSO-SDF — Secure Defaults (SHOULD)
*"Providers SHOULD set all settings to their recommended secure defaults"
for administrative and privileged accounts upon initial provisioning.*

**How this guide meets it:** documented shipped defaults already align in
part — new users are Execute-only by default (§6.3), Read is force-enabled
with grants, admin privileges are scoped by default, third factor is
mandatory for system administrators, and policy acceptance blocks login
until accepted. §11 lists the full baseline; the remaining
default-vs-configured split is a flagged TODO.

### SCG-ENH-CMP — Comparison Capability (SHOULD)
*"Providers SHOULD offer the capability to compare all current settings" to
recommended secure defaults.*

**What the rule asks for:** the ability to compare *all* of a tenant's current
settings against the provider's recommended secure defaults, so an operator can
see at a glance which settings are non-compliant.

**Status: met procedurally today; a small automation closes it fully.** There
is no one-click "compare to secure defaults" screen yet. Today the comparison
is a **manual** diff of the tenant's live values (read in the Configuration
Items processes, or via `SLCT_SRC_PRPT` / `GetSecurityOptions` over the signed
API) against the §11 checklist, performed during the monthly privileged-account
review (§7.2).

**Approach to automate (concrete, low-effort):** because every comparable
setting already lives in one `ADVENT_SRC_PRPT` row with a known recommended
target, add one read-only SP — `COMPARE_SRC_TO_BASELINE(V_SRC_ID)` — that joins
the tenant's row against a small baseline table (`setting_name`,
`recommended_value`, `comparator` such as `>=`/`=`/`in-set`) and returns, per
setting: current value, recommended value, and a `COMPLIANT` Y/N flag (plus a
summary count). Surface it as an E_MYSQL service in a "Security Baseline
Comparison" process (or a read-only panel in the Administrator profile) and, if
wanted, expose the same SP over the signed REST API so it is machine-readable
(dovetails with SCG-ENH-EXP/API). The recommended-value table is the §11
checklist encoded once. Effort: one SP + one seed table + one process — no
engine or schema change. Until built, SCG-ENH-CMP is satisfied procedurally.

### SCG-ENH-EXP — Export Capability (SHOULD)
*"Providers SHOULD offer the capability to export all security settings in a
machine-readable format."*

**Substantially met.** The Administrator profile provides full bidirectional
**bulk export *and* import** (`.xlsx`, machine-readable) for the entire RBAC
configuration — not just users/groups/roles but also **authorization grants**
(role↔auth-item privilege assignments):

| Entity | Export | Import | Endpoint / SP |
|---|---|---|---|
| Users | ✅ | ✅ | `ExportUsers` / `UserProvisioningService.bulkImportUsersFromExcel` |
| Groups | ✅ | ✅ | `ExportGroups` / `SYNC_UPLOADED_GROUPS` |
| Roles | ✅ | ✅ | `ExportRoles` (`EXPORT_ROLES_FOR_SRC`) / `ADD_ROLE_DL` |
| **Authorizations** (PROCESS/SERVICE/EXE/USER/GROUP/ROLE → role, with CRUDE) | ✅ | ✅ | `ExportAuthorizations` (`EXPORT_AUTHORIZATIONS_FOR_SRC`) / `ADD_AUTHORIZATION_DL` |

Gesture: profile menu → Download/Upload → pick Users / Groups / Roles /
Authorization → `.xlsx` (round-trips). (ARTIFACT grants are excluded by
design — documents use ABAC, not role grants; Platform/Machine auth types are
not part of this export set.)

The remaining **tenant security settings** (MFA config, session/lockout policy,
password policy, file-scan/watermark, retention) live in one `ADVENT_SRC_PRPT`
row and are retrievable via the signed API (`SLCT_SRC_PRPT` /
`GetSecurityOptions`, §12 SCG-ENH-API) but are **not yet bundled into a single
settings-export file**; the domain allowlist is Advent-controlled (not
tenant-exportable). So: RBAC + authorization export/import is fully machine-
readable today; a one-call `ADVENT_SRC_PRPT` exporter would close the last gap.
Detail: `TENANT_SECURITY_CONFIGURATION_GUI.md` §7, ADMINISTRATOR_MODULE.md.

### SCG-ENH-API — API Capability (SHOULD)
*"Providers SHOULD offer the capability to view and adjust security settings
via an API or similar capability."*

**Yes — via the signed SP-over-REST surface.** All API requests carry a
SHA-256 digital signature with replay protection (request must arrive within 15
minutes of its timestamp, customer-configurable) (SSP Appendix A). Tenant
security settings **can** be viewed and adjusted through this API because the
Configuration Items processes are themselves nothing but stored-procedure calls
over the generic signed executor
`/rest/v1/securedJSON?REST_Service=<SP>&Verb=<GET|POST>`: **read** via
`SLCT_SRC_PRPT`, `GetSecurityOptions`, `GetPasswordPolicy`, `GetFilePolicy`,
`GetDataPolicy`, `GetMultiFactorInfo`; **write** via `UPDT_SRC_PRPT` and the
per-policy submit path. Each call is gated by the Execute privilege on its
process (same authorization as the GUI). Caveat for the assessor: this is the
platform's **generic** signed SP-over-REST surface, not a separately-documented
"settings API," and write authorization is enforced at the process-Execute
layer (see `enablement_angular/ACCESS_CONTROL_HARDENING_PLAN.md`). Detail:
`TENANT_SECURITY_CONFIGURATION_GUI.md` §8.

### SCG-ENH-MRG — Machine-Readable Guidance (SHOULD)
*"Providers SHOULD also provide the Secure Configuration Guide in a
machine-readable format."*

**How this guide meets it:** this guide is authored in Markdown and is
paired with the machine-readable `/20x/package` manifest declared in the
header, consistent with Advent's 20x machine-readable package approach.

### SCG-ENH-VRH — Versioning and Release History (SHOULD)
*"Providers SHOULD provide versioning and a release history" as secure
defaults evolve.*

**How this guide meets it:** the header carries the version (1.0,
2026-08-07) and the Release History table below is appended on every
revision, mirroring the change-history practice used in Advent SOPs
(e.g., Administrator SOP change-history table).

---

## 13. TODO resolution status (2026-07-13)

All eleven consolidated TODOs from v0.3 are resolved in the body, except two
publish-approval actions that are Advent business decisions (items 1, and the
CMP/EXP automation is roadmap-optional). Grounded against prod
(SRC 1724/1711) and the canonical Advent docs.

| # | Item | Status | Where resolved |
|---|---|---|---|
| 1 | Public SCG URL + package listing (SCG-CSO-PUB/AUP) | **Resolved** — published live: SCG at `enablement.cc/ml/20x/scg` (machine-readable markdown), Trust Center `/ml/20x/trust`, CPO package `/ml/20x/package`, authenticated KSI evidence API `/ml/20x/ksi`. Header promoted out of DRAFT to version 1.0 on 2026-08-07 (System Owner approval, signature on file). | §1 URL table, §12 SCG-CSO-PUB |
| 2 | Tenant decommissioning workflow | **Built & E2E-tested** — "Decommission an Organization" process (Support app, SRC 1711): source dropdown → typed confirmation → transactional cascade delete of all org data + cryptographic erasure. Protected orgs refused. | §2.3 |
| 3 | Email-domain allowlist ownership | **Resolved** — central Advent-support `ADVENT_DMN` table (`CHK_DMN`), enforced at login + Add User; not client-editable. | §3.2, `TENANT_SECURITY_CONFIGURATION_GUI.md` §9 |
| 4 | Failed-attempt / session-timeout screen | **Resolved** — Configuration Items → Inactivity Policy; new companion doc maps every field ↔ `ADVENT_SRC_PRPT` column. | §5, new `TENANT_SECURITY_CONFIGURATION_GUI.md` |
| 5 | Audit-record export procedure | **Resolved** — XLS/PDF/PNG export on the audit table + scheduled emailed User Audit Report (anomaly scoring). Monitor = on-screen only. | §9 |
| 6 | Pre-expiry share revocation + effect | **Resolved** — synchronous `RevokeShare` (optional cascade); revoked recipient loses resolve/download; pre-revocation downloaded copies not recalled. | §10.2 |
| 7 | Auto-created recipient account privileges/lifetime | **Resolved** — base `Enablement` group, ACTIVE, `showprofile` landing surface, least privilege; no account expiry (share/message expiry only). **Explicit account expiry is NOT required for 20x** — AC-2(3) inactivity auto-disable (35 d) covers it; a fixed expiry is optional hardening. | §10.3 |
| 8 | Shipped default vs agency-configured (rows 1–5) | **Resolved** — column defaults = shipped; rows 1–5 (esp. password `Min_Length=6`) are agency-hardened via Configuration Items; platform-enforced items are secure-by-default. | §11, companion §6 |
| 9 | Settings-comparison capability (SCG-ENH-CMP) | **Explained + approach given** — no one-click compare today; done manually against §11; concrete low-effort automation specified (`COMPARE_SRC_TO_BASELINE` SP + baseline table + read-only panel/API). | §12 SCG-ENH-CMP |
| 10 | Export coverage (SCG-ENH-EXP) | **Substantially met** — full bulk export *and* import of Users/Groups/Roles **and authorization (auth-item→role) grants** as `.xlsx` (Administrator profile). Only remaining gap: a single `ADVENT_SRC_PRPT` security-settings bundle (roadmap-optional; settings are already API-retrievable per-SP). | §12 SCG-ENH-EXP, companion §7 |
| 11 | Security settings via signed REST API (SCG-ENH-API) | **Resolved (yes)** — Configuration Items settings read/write over the signed `securedJSON` SP executor (`SLCT_SRC_PRPT`/`UPDT_SRC_PRPT` etc.), Execute-gated. | §12 SCG-ENH-API, companion §8 |

**Remaining actions:** none blocking. Item 1 is closed — the header was
promoted out of DRAFT to version 1.0 on 2026-08-07 and publication is live at
`/ml/20x/scg`. Optional roadmap enhancements
that would turn "manual/partial" into "automatic": a settings-comparison SP
(item 9, `COMPARE_SRC_TO_BASELINE`) and a single `ADVENT_SRC_PRPT`
security-settings export SP (item 10). Neither blocks a compliance assertion.

---

## 14. Securely Configuring an App You Build on the Platform (PaaS Layer)

**Audience for this section only: the agency's app/process builders** — the
staff who use Enablement's no-code designer to author their own processes,
forms, and dashboards on top of the platform (the **PaaS** layer), as opposed
to the tenant administrators addressed in §1–§13. This section is Advent's
secure-use guidance for that audience, matching what a customer building on a
PaaS offering is expected to receive alongside the provider's own hardening.

**Where the control split lives.** The Customer Responsibility Matrix (CRM)
for the PaaS layer — which controls Advent (the provider) owns outright, which
are shared, and which the customer owns when they build on the platform — is
being formalized as **Appendix J** of the SSP (source: `PAAS_SSP_INSERTS.md`,
authored in parallel with this section). Every subsection below states which
side of that split it falls on. See also
`TENANT_SECURITY_CONFIGURATION_GUI.md` for the tenant admin screens that back
the RBAC and marking mechanisms referenced here, and §6 (RBAC) and §10
(file-security features) of this guide for the underlying platform
mechanisms this section applies to app-builders specifically.

### 14.1 Least-privilege roles for the processes/apps you build

Apply the RBAC model in §6.1–§6.3 when authorizing your own processes, not
just when administering the tenant generally:

- **Grant PROCESS auth narrowly.** Attach a new process/app to the role(s)
  that actually need it — not to every role in the organization "to be safe."
  A `PROCESS` grant on a role auto-cascades the process's `SERVICE` auths
  (`ADD_AUTH_ROLE_THRU_ID`), so granting the process is sufficient; there is
  no separate step that would tempt over-granting service-level access
  (§6.3, ACCESS_CONTROL.md).
- **New users are Execute-only by default** (§6.3) — leave it that way for
  ordinary app users. Only grant Create/Update/Delete/Design on your
  process to the specific person(s) who build or maintain it.
- **Executables, Machines, and Platforms only belong in a role for the
  people who create/update/delete them** — not for users who merely run your
  process (§6.3). Keep infrastructure objects out of an app-user's role
  entirely.
- **Reuse framework roles instead of inventing parallel grants** where one
  already exists for the capability you need (e.g., the **"Enablement
  Workflow Dashboard Role"** gates the Dashboard menu; see §14.3). Framework
  roles live in the `Enablement Framework` source and are the platform's
  documented, exact-string capability switches — see `ACCESS_CONTROL.md`.
- **Caution — privilege changes propagate.** Changing an auth item's CURDE
  privileges on one role auto-applies the same change to every *other* role
  that also carries that item (§6.3). Before tightening or loosening access
  on a shared process, check which other roles carry it.
- Artifact-level grants default to the owner and the owner's group; only add
  role-based artifact grants for a documented, owner-approved purpose (§6.3).

**Responsibility:** Customer (you configure roles/auth items for your own
processes using platform-provided RBAC primitives; the engine enforces
whatever you configure).

### 14.2 Data marking — mark forms/fields by sensitivity

Two independent marking mechanisms are available when you design a form; use
the one that matches what you are collecting.

- **Field-level marking (`Is_Secured`).** Every field property on a manual
  form or process form supports the enum **`None` / `Personal` / `System`**
  (`BPM_CFG.ADVENT_SRVC_PARAMS_PROP.Is_Secured`):
  - `None` (default) — plaintext, shown as-is. Use only for genuinely
    non-sensitive fields.
  - `Personal` — encrypted with the **saving user's own session key**;
    decrypted only when that same user reloads the form. Use only when the
    saver is the sole reader (e.g., a personal draft note) — a reviewer or
    any other user cannot decrypt it.
  - `System` — encrypted with a **per-tenant (source) key**, so any
    authorized user in your organization can use the value, but the form
    **always renders it masked (`********`)** — it is never decrypted
    client-side. Use this for data any authorized user in your app must be
    able to rely on but that must stay encrypted at rest and off-screen
    (SSNs, credentials, other source-shared secrets).
  - Mark any field holding PII, CUI, or other sensitive data `System` (not
    `None`); do not use `Personal` for anything a second user will ever need
    to read. Source: `IS_SECURED_MANUAL_FORMS_STATUS.md` § "`Is_Secured`
    modes — the canonical three-value enum".
- **File/artifact marking (CUI and distribution codes, §10.1).** Files your
  app's users upload through an `INPUT_ARTFCT_TASK` (artifact) form step get
  the same CUI-categories + distribution-code marking dialog, banner
  (`CUI // <categories> // <distribution>`), and auto-detection-of-existing-
  marking behavior available anywhere else in the platform (§10.1).

**How marking drives visibility:** `None` fields are always visible as
entered; `Personal` fields are visible only on reload by the same saving
user; `System` fields are never visible on any form after save (mask only —
server-side processes can still consume the real value). CUI/distribution
markings drive the banner and designation block shown on the file/document
itself, independent of the field-level mechanism above.

**Responsibility:** Customer (you choose the `Is_Secured` mode per field and
the CUI/distribution markings per artifact when you design the form; the
platform enforces the chosen mode's encryption/masking behavior).

### 14.3 Share rules

Two share surfaces exist inside an app you build; scope both narrowly.

- **Dashboard/chart sharing.** A dashboard owner picks a share scope —
  `Organization`, `Group`, `User`, or `Public` — and, for `User` scope, an
  explicit recipient list. Sharing **never grants edit rights**: a recipient
  always sees the owner's dashboard in **read-only preview** first, and must
  take an explicit **"Use It"** action to adopt it — which **copies** the
  owner's chart configuration into the recipient's own, independently-owned
  copy (the recipient can then freely re-personalize it; the owner's config
  is never mutated, and the recipient's copy starts fully private — none of
  the owner's own share settings carry over). Adoption additionally requires
  the recipient to (a) hold the relevant framework role (e.g., "Enablement
  Workflow Dashboard Role") and (b) be able to run the process that produces
  the dashboard — a share alone cannot expose a dashboard to someone who
  isn't otherwise authorized to run the underlying process. **Default to the
  narrowest scope** (`User` or `Group`) rather than `Organization` or
  `Public` for anything sensitive. Source: `DASHBOARD.md` → "Recipient
  Review & Re-Personalization Flow".
- **Secured file/folder sharing (§10.2).** For artifacts your app's users
  upload or exchange, share per-recipient (not organization-wide), rely on
  the tenant's **Shared File Expiry** time-box, and revoke pre-expiry when
  access is no longer needed (`RevokeShare`, immediate and synchronous). For
  anything sensitive, prefer the non-download access levels (metadata /
  watermark / read-only preview, §10.4) over full download — a downloaded
  copy cannot be recalled even after you revoke the share.
- **Avoid over-broad shares generally:** the platform's own default for an
  auto-created recipient account is least-privilege (no workflow/design/
  admin rights, landing-surface-restricted, §10.3) — apply the same
  narrowest-scope discipline yourself when you choose a share's audience.

**Responsibility:** Customer (you choose share scope/recipients/expiry for
your own app's dashboards and files; the platform enforces whatever scope
you configure and provides the revoke/expiry mechanisms).

### 14.4 Input validation for your process/form inputs

- **What the platform validates (Provider):** every submission to a
  process/manual-task form is checked against the structural contract
  defined by `ADVENT_SRVC_PARAMS_PROP` (field types, the `Is_Secured`
  encryption round-trip described in §14.2) before it reaches a service, and
  artifact uploads additionally pass malware scanning plus the optional
  sensitive-word / restrictive-language checks (§10.5). This is envelope-level
  validation — it confirms the submission is well-formed and safe, not that
  it is *correct* for your business process.
- **What you own (Customer):** the business-semantic correctness of the data
  your process collects — e.g., that a field is a plausible SSN format, that
  a selected value corresponds to a real record, that two fields are
  mutually consistent — is not something the platform can infer from a
  generic field type. Build this into your design:
  - Use **required-field** flags rather than relying on downstream code to
    reject blanks.
  - Prefer **constrained dropdowns** over free text wherever the value must
    match a known set — `Optional_Values` on the field property, or an
    app-named lookup table via `SLCT_DBPARAM`, both resolved automatically
    into the form's options (see the SchemaColumns/SLCT_DBPARAM mechanism
    used elsewhere in the platform).
  - Add a validating **service task** ahead of any downstream step that
    assumes a specific format or cross-field invariant the generic field
    contract can't express.
- This split maps to **SI-10 (Information Input Validation)** in the CRM
  (Appendix J, `PAAS_SSP_INSERTS.md`): a **shared** control where Advent
  validates the structural/security integrity of every submission and the
  customer is responsible for the business-rule validation specific to the
  process they designed.

**Responsibility:** Shared (Provider: envelope/structural/security
validation, always on, not configurable off. Customer: business-rule
validation for your own process, which you must design in).

### 14.5 Tenant isolation is enforced for you (Provider responsibility — nothing to build)

- Every request — GUI, REST, and the SP layer underneath — executes under a
  **server-authoritative tenant binding** (`SRC_ID`) resolved from the
  authenticated session, never from client-supplied input. An app you build
  cannot address, read, or write another tenant's data by manipulating a
  form value, a URL parameter, or a REST payload field, because the binding
  is enforced at the data-access layer beneath every SP call, independent of
  what your process/form sends.
- This is a **pure Provider responsibility** in the CRM (Appendix J,
  `PAAS_SSP_INSERTS.md`): **you do not need to add tenant-scoping logic to
  your own processes, service tasks, or forms.** Design roles, dropdown
  option sources, and service calls as if your organization's data is the
  only data that exists — the engine will not return or accept another
  tenant's rows regardless of how your app is designed.
- This is regression-tested on prod, not merely asserted: the cross-tenant
  isolation suite (KSI-SVC-PRR / SC-4, `TENANT_ISOLATION_SUITE_DESIGN.md`)
  exercises both the **read** axis (SP-lookup scoping, REST/IDOR probes with
  minted session-equivalent tokens) and the **write** axis — a tenant-A
  session attempting a designer write (e.g., process-parameter update)
  against tenant-B's process is verified **blocked (403)** while the
  same-tenant control write is accepted (both lanes **PASS** on prod as of
  2026-07-18; see that doc for the daily-cron evidence trail).

**Responsibility:** Provider (fully enforced by the platform's tenant-binding
layer; no customer configuration exists for this, by design — there is
nothing for an app-builder to turn on, off, or misconfigure).

---

## Release History

| Version | Date | Author | Description |
|---|---|---|---|
| 1.0 (2026-08-07): approved for publication — signature on file | 2026-08-07 | Advent Business Company Inc. | Promoted from 0.5 DRAFT to 1.0. No technical content changed; the DRAFT marker was removed, the header version and date were updated, and §12 SCG-ENH-VRH / §13 item 1 were corrected to record that the last open publication action is closed. Approved by the System Owner; the approval cover sheet carries the SHA-256 of this file at approval and is held with the signed 20x package. |
| 0.5 (2026-07-18): PaaS customer secure-use guidance | 2026-07-18 | Advent Business Company Inc. | Added **§14 "Securely Configuring an App You Build on the Platform (PaaS Layer)"** — secure-use guidance for customers building no-code apps/processes on the platform: least-privilege PROCESS/auth-item roles (§14.1), field-level `Is_Secured` data marking + CUI/distribution file marking (§14.2), dashboard/folder share-scoping and the "Use It" adopt flow (§14.3), the platform-vs-customer input-validation split mapped to SI-10 (§14.4), and tenant isolation as a Provider responsibility with prod-verified read+write KSI-SVC-PRR PASS evidence (§14.5). Cross-references the CRM (SSP Appendix J, `PAAS_SSP_INSERTS.md`, authored in parallel), `TENANT_SECURITY_CONFIGURATION_GUI.md`, and the already-PASSing read+write cross-tenant regression evidence in `TENANT_ISOLATION_SUITE_DESIGN.md`. Added a §1 outline entry for the new section. |
| 0.1 DRAFT | 2026-07-09 | Advent Business Company Inc. | Initial draft assembled from Administrator SOP (ADM-0010-20), MFA SOP v1.0, Log-In User Guide v1.04, Passkey User Guide v1.01, and User Management with RBAC SOP v1.01, structured against the FedRAMP 20x Class C SCG ruleset. |
| 0.3 (2026-07-10): code-verified auth corrections | 2026-07-10 | Advent Business Company Inc. | Password reset (login-page OTP flow + in-app) verified to preserve encrypted data via password-independent V_MASTER_SEED — removed the forgotten-password data-loss trade-off (§3.4); password changes no longer revoke passkeys — revocation is the explicit Revoke Passkey dialog (§4.3); documented pre-login FingerprintJS visitor-ID risk gating + reCAPTCHA v3 (§3.5, new); documented Enablement PDNS Agent with macOS/Windows installers (§3.6, new). Customer-facing Login/Passkey User Guide PDFs still carry the old statements and need regeneration. |
| 0.4 (2026-07-13): §13 TODOs resolved + tenant off-boarding built | 2026-07-13 | Advent Business Company Inc. | Built & E2E-tested the **tenant-decommissioning** workflow ("Decommission an Organization", Support app SRC 1711: `DECOMMISSION_SRC` SP → `DecommissionSource` E_MYSQL → source-dropdown + typed-confirmation process; transactional all-org cascade delete + cryptographic erasure; protected-org guard) — §2.3. Resolved the remaining §13 TODOs against prod (SRC 1724/1711): domain allowlist ownership (§3.2), failed-attempt/session-timeout screen (§5), audit export + scheduled anomaly report (§9), pre-expiry share revocation (§10.2), auto-created recipient accounts (§10.3), shipped-vs-configured defaults (§11), and SCG-ENH-CMP/EXP/API (§12). Added companion **`TENANT_SECURITY_CONFIGURATION_GUI.md`** (Configuration Items + User Management ↔ `ADVENT_SRC_PRPT`) + DOCMAP row. Follow-up same day: recorded the **live published URLs** (SCG `/ml/20x/scg`, Trust Center `/ml/20x/trust`, CPO `/ml/20x/package`, KSI API `/ml/20x/ksi`) closing SCG-CSO-PUB/AUP (§1); corrected SCG-ENH-EXP to include **authorization (auth-item→role) bulk export/import** (§12); clarified auto-created-account expiry is not a 20x requirement (§10.3); gave the concrete comparison-SP approach (§12 SCG-ENH-CMP). Open: promote header out of DRAFT; optional roadmap SPs for settings-comparison and single-file settings export. |
| 0.2 (2026-07-09): TODOs resolved from Rev5 package sources | 2026-07-09 | Advent Business Company Inc. | Resolved 11 of 17 TODOs using SSP Appendix A control implementations (AC-2(2)/(3), AC-7, AC-8, AC-11/AC-12, IA-5(1), AU-7, MP-6), Appendix Q crypto modules, Rev5 evidence screenshots, and Advent feature documentation (secured files/email encryption, CUI markings, watermarking); added §10.1–10.5 and consolidated Open TODOs (§13). |