> **FedRAMP ID FR2628647239** — Enablement®, Advent Business Company Inc. Certification Package Overview: https://enablement.cc/ml/20x/package?src_id=1711
>
> This line is added by the trust center when the document is served. The document body below is the signed artifact, unmodified.

# Enablement® Secure Configuration Guide (SCG)

Status: Live reference · Last-verified: 2026-07-13 · v1.1 SIGNED 2026-09-15 (Rajesh Gupta, System Owner; v1.0 signed 2026-08-07) · served publicly (no token) at `https://enablement.cc/ml/20x/scg`
Layer: Cross-repo
Siblings: Access Control Policy (`https://enablement.cc/ml/20x/doc/policy-access-control`) · FedRAMP certification package manifest (`https://enablement.cc/ml/20x/package?src_id=1711`)
Aliases: SCG, secure configuration guide, MFA setup, passkeys, RBAC, session timeout, lockout, audit log access, CUI markings, secured files, secured email, watermarking, malware scanning, PaaS secure configuration, tenant isolation
Sections: 1. Scope and How to Use This Guide · 2. Top-Level Administrative Accounts · 3. Authentication Policy Options (per organization) · 4. Passkeys (Phishing-Resistant Authentication) · 5. Session, Lockout, and Inactivity Controls · 6. Role-Based Access Control (RBAC) · 7. User Lifecycle (Onboarding → Review → Deactivation) · 8. System-Use Notification / Policy Acceptance at Login · 9. Audit-Log Access · 10. File-Security Features (CUI / Distribution Markings, Secured Files & Email) · 11. Recommended Secure Defaults: Checklist · 12. How This Guide Meets Each SCG Rule · 13. TODO resolution status (2026-07-13) · 14. Securely Configuring an App You Build on the Platform (PaaS Layer) · Release History

| | |
|---|---|
| **Product** | Enablement®, workflow automation and secure content platform |
| **Provider** | Advent Business Company Inc. |
| **Certification target** | FedRAMP 20x, Class C |
| **Document version** | 1.1 (signed 2026-09-15) |
| **Date of last update** | 2026-09-14 |
| **Signature** | Signed (wet signature image) 2026-09-15, Rajesh Gupta, System Owner |
| **Machine-readable companion** | `https://enablement.cc/ml/20x/package?src_id=1711` 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 to §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 Advent maintains the as-built hardening, the deviation
register, and the full NIST-800-53 / CMMC-L2 control mapping in its host hardening baseline.
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 (its stored public keys and per-user AES seed records) 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** (blocked domains, permitted full domains, and 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. |
| **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 to 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,
  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 the application, 2026-07-10)

Before the credential form is displayed, the login page runs an automated-abuse check, and the form is
withheld until the check passes:

- A device identifier is established in the browser and later bound into authentication and
  passkey-registration calls for per-device tracking.
- The check assesses whether the session shows signs of automation or emulation. A session judged to
  be automated is blocked from logging in with a risk-verification message. How strict the check is can
  be configured per tenant.
- The **Forgot Password** flow is additionally gated by Google **reCAPTCHA v3** before a one-time code
  is issued, throttling automated reset-code harvesting.
- If the check itself cannot complete, the login form is shown: availability is preferred over a
  hard-closed login for an infrastructure fault.

**Security impact:** automated traffic is filtered before it can exercise the authentication
endpoints, and the strictness is tunable per tenant when an agency wants stricter automation blocking.

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

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 the Quad9 public resolver 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**: an installer package that installs the agent as a launch
    daemon; run it with administrator rights.
  - **Windows**: a zip archive containing the agent executable (x64 and
    arm64 included), which installs as a Windows Service when its install
    option is run as Administrator.
- The app detects the agent through health endpoints the agent serves on
  the device's loopback interface (HTTP, and HTTPS with a self-signed
  certificate 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 to 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 to 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: the failed-login attempt threshold, whether an administrator must unlock a locked account, the inactivity logout timeout in minutes (AC-12), the idle screen-lock time in minutes (AC-11), and the inactivity auto-disable threshold in days (AC-2(3)). All are saved to the organization's tenant security settings. | 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 to 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 to 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** (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 a per-tenant
setting (Daily, Weekly, or off) run by a Quartz trigger;
each run, even a zero-anomaly one, writes a dated entry to the platform audit log 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). Process monitoring has a parallel
anomaly capability (per-user execution-pattern analysis) plus a kill-switch that
stops a single process instance or all of a user's processing; its
per-instance/chart views are on-screen only (no export/schedule documented).

---

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

Secured content is integrated with the identity model of §3 to §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>`.
- **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:
  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:
  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").
- **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 to 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** (the optional cascade follows the chain of re-shares, and a
  bulk operation handles batches), recording when and by whom access was
  revoked and writing an audit entry. **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; the revocation record in the
  database 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.

### 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 bodies and attachments use the same client-side encryption
  path as Secured Files (per-recipient wrapped keys; "secure email
  ciphertext, per-recipient bundles" stored encrypted in S3) (source:
  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 the platform's single user-provisioning service (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** 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 compliance review
  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 auto-disable threshold (days). The "Expires in N days" the recipient
  sees is the **share/message expiry** (each share's own expiry date, bounded by
  the tenant's Shared File Expiry setting), not an account expiry.
- **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 (each share's own expiry
  date, bounded by the tenant's Shared File Expiry setting), 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.
- 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 (the ClamAV daemon behind a 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 entry; 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 to 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 to 5).** Every setting ships with
a default seeded at provisioning (the stored default in the tenant security settings); 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 to 5 are **agency-configured, not shipped-secure**:
row 1 (MFA) ships enabled-capable (MFA options shown, 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**
(minimum length 6, every character-class minimum 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 to 12).

---

## 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 to §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 + `https://enablement.cc/ml/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 (`https://enablement.cc/ml/20x/trust`) and the CPO
package manifest (`https://enablement.cc/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 through 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 is already stored in one per-tenant settings record with a known
recommended target, add one read-only database routine that compares the
tenant's settings against a small baseline table (setting, recommended value,
and a comparison rule such as at-least, equals, or one-of) and returns, per
setting: current value, recommended value, and a compliant Y/N flag (plus a
summary count). Surface it as a service in a "Security Baseline
Comparison" process (or a read-only panel in the Administrator profile) and, if
wanted, expose the same routine 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 routine + 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 |
|---|---|---|
| Users | ✅ | ✅ |
| Groups | ✅ | ✅ |
| Roles | ✅ | ✅ |
| **Authorizations** (Process, Service, Executable, User, Group, and Role items → role, with CRUDE) | ✅ | ✅ |

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) are stored in one per-tenant
settings record and are retrievable via the signed API (§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 exporter for the
tenant settings record would close the last gap.

### 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 platform's generic signed stored-procedure executor: **read** calls
return the tenant settings record and the security, password, file, data, and
multi-factor policies; **write** calls update the tenant settings record
through 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.

### 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 `https://enablement.cc/ml/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.1,
2026-09-14) 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 two production
tenants and Advent's canonical internal documentation.

| # | Item | Status | Where resolved |
|---|---|---|---|
| 1 | Public SCG URL + package listing (SCG-CSO-PUB/AUP) | **Resolved**, published live: SCG at `https://enablement.cc/ml/20x/scg` (machine-readable markdown), Trust Center `https://enablement.cc/ml/20x/trust`, CPO package `https://enablement.cc/ml/20x/package`, authenticated KSI evidence API `https://enablement.cc/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, production tenant): 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 domain allowlist maintained by Advent support, enforced by the login check + Add User; not client-editable. | §3.2 |
| 4 | Failed-attempt / session-timeout screen | **Resolved**. Configuration Items → Inactivity Policy; a new internal companion reference maps every field to its stored tenant setting. | §5 |
| 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 share revocation (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, Secured Files or Secured Email 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 to 5) | **Resolved**, stored setting defaults = shipped; rows 1 to 5 (esp. password minimum length 6) are agency-hardened via Configuration Items; platform-enforced items are secure-by-default. | §11 |
| 9 | Settings-comparison capability (SCG-ENH-CMP) | **Explained + approach given**, no one-click compare today; done manually against §11; concrete low-effort automation specified (read-only comparison routine + 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 security-settings export bundle (roadmap-optional; settings are already retrievable through the signed API). | §12 SCG-ENH-EXP |
| 11 | Security settings via signed REST API (SCG-ENH-API) | **Resolved (yes)**. Configuration Items settings read/write over the signed stored-procedure executor (read and update calls), Execute-gated. | §12 SCG-ENH-API |

**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
`https://enablement.cc/ml/20x/scg`. Optional roadmap enhancements
that would turn "manual/partial" into "automatic": a settings-comparison routine
(item 9) and a single security-settings export routine (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 to §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 (drafted in parallel with this
section). Every subsection below states which side of that split it falls on.
See also §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 to §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 automatically cascades to the process's Service
  authorizations, so granting the process is sufficient; there is
  no separate step that would tempt over-granting service-level access
  (§6.3).
- **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 are defined in the platform's framework organization and are the
  platform's documented capability switches, matched by exact role name.
- **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 (secured mode).** Every field property on a manual
  form or process form supports three secured modes, **None / Personal / System**:
  - 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 (asterisks)**, 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.
- **File/artifact marking (CUI and distribution codes, §10.1).** Files your
  app's users upload through an artifact-upload 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 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.
- **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 (revocation is 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 the form's field-property configuration (field types, the
  secured-mode 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, either a fixed list of optional values on the field
    property or a lookup table your app names, both resolved automatically
    into the form's options.
  - 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): 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** 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):
  **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)
  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; the suite runs daily and those runs form the 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.1 (2026-09-15): signed | 2026-09-15 | Advent Business Company Inc. | v1.1 signed by Rajesh Gupta, System Owner; wet signature applied to the regenerated DOCX, PDF issued. Content is the 2026-09-14 approach-level revision. |
| 1.1 DRAFT (2026-09-14): approach-level revision | 2026-09-14 | Advent Business Company Inc. | Proprietary-detail revision under the owner decision of 2026-09-14: internal implementation identifiers (code, service, database, table, column and procedure names, internal endpoint paths, local ports, installer file names and commands) were replaced with approach-level descriptions of the same measures, and references to documents outside the served package were replaced with descriptions of their content, or removed where the section already stated that content. No control statement, commitment, disclosed limitation, non-claim or date was removed. Short endpoint paths were written out as full URLs, and the header version, date and signature rows and §12 SCG-ENH-VRH were updated to 1.1. No DOCX or PDF rendition was regenerated. Later the same day: §3.5 now states the automated-abuse protection at the approach level; the specific detection signals, the default block score and the check timeout were removed from this public document, and the fail-open behavior stays disclosed. |
| 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 secured-mode 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, drafted in parallel), Advent's internal tenant security configuration reference, and the already-PASSing read+write cross-tenant regression evidence in Advent's internal tenant-isolation suite design. 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 the password-independent 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 the pre-login automated-abuse check and reCAPTCHA v3 gating (§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 on the production tenant: a database routine run from a process with an organization dropdown and typed confirmation; transactional all-org cascade delete + cryptographic erasure; protected-org guard), §2.3. Resolved the remaining §13 TODOs against two production tenants: 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 an internal companion reference mapping the Configuration Items and User Management screens to the stored tenant settings. Follow-up same day: recorded the **live published URLs** (SCG `https://enablement.cc/ml/20x/scg`, Trust Center `https://enablement.cc/ml/20x/trust`, CPO `https://enablement.cc/ml/20x/package`, KSI API `https://enablement.cc/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 routines 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 to 10.5 and consolidated Open TODOs (§13). |