Secure Configuration Guide

VirtualDojo AI CRM — FR2615441197

---

Front Matter: Scope and Rule Coverage

This guide is VirtualDojo's Secure Configuration Guide as required by the FedRAMP 20x Consolidated Rules Secure Configuration Guidance (SCG) ruleset. It is written for the people who will actually operate a VirtualDojo AI CRM tenant — agency tenant administrators, ISSOs, and anyone holding a top-level administrative or privileged account — not for FedRAMP assessors. It satisfies:

The optional enhanced-capability items (SCG-ENH-*) are tracked in Section 9 (Enhanced Capabilities Roadmap), which states the current status of each — some are implemented today and others are on the roadmap.

1.1 Relationship to Other Package Documents

This guide is a distillation of controls that are documented in full elsewhere in the FedRAMP Certification Package. Where this guide says "configure X," the underlying control implementation, evidence, and verification procedure are documented in:

• Identification and Authentication Policy — organizational password, MFA, and session policy
• Authentication and Federation Procedures — the operational procedures behind IA-5(1), IA-5(2), IA-7, IA-8, IA-8(1), IA-8(2), IA-8(4) (password configuration, Entra Certificate-Based Authentication, SAML federation, PIV/CAC acceptance)
• Access Control Policy — role-based access control, Conditional Access, and privileged session limits
• Audit Log Review Checklists — audit log sources and review cadence
• Customer Responsibility Matrix — the full CSP-vs-customer responsibility split by control

If any statement in this guide appears to conflict with those documents, the control implementation documents govern; this guide is the summarized, customer-facing operational version and is updated whenever the underlying configuration changes.

1.2 How to Obtain This Guide (SCG-CSO-AUP)

This guide is included as a named artifact in the VirtualDojo FedRAMP 20x Certification Package (this file, Secure Configuration Guide / its signed PDF rendering in the signed certification package) and is also published independently of the certification package at the public URL in Section 1.3. Agencies evaluating or onboarding to VirtualDojo AI CRM should:

1. Read this guide before assigning the first top-level administrator account for their tenant.
2. Complete the initial admin setup steps in Section 2 and record completion in the agency's own onboarding checklist.
3. Re-read Section 7 (Secure Defaults) whenever VirtualDojo publishes a Significant Change Request (SCR) that touches authentication, session, or access-control behavior — SCRs are announced via the Trust Center (https://trust.virtualdojo.com) and to the tenant's registered admin contact.
4. Direct configuration questions to security@virtualdojo.com.

1.3 Public Availability (SCG-CSO-PUB)

This guide is published at https://trust.virtualdojo.com/secure-configuration-guide, hosted on the VirtualDojo Trust Center. It does not require an account, a customer relationship, or an NDA to view — it is intended to be readable by prospective agency customers during procurement evaluation, not only by existing tenants. The Trust Center copy is kept in sync with the version in the signed Certification Package; the Certification Package version is authoritative in case of a discrepancy pending republication.

---

2. Top-Level Administrative Accounts

2.1 What a Top-Level Administrator Is

In VirtualDojo AI CRM, the top-level administrative role is superadmin. A superadmin account controls enterprise-wide access to the entire tenant: it can create and remove other admins, change tenant-wide security settings, configure SSO/federation trust, and read the full audit log. There is exactly one class of account with this scope per tenant; VirtualDojo strongly recommends limiting the number of live superadmin holders to the minimum needed for continuity (typically 2, so a single person's unavailability does not block emergency access changes).

superadmin is distinct from the admin role, which is a privileged-but-scoped role (see Section 3) — an admin manages users and day-to-day settings within the tenant but cannot alter the settings enumerated in Section 2.4.

2.2 Provisioning a New Top-Level Administrative Account

1. The account must be created under the agency's own identity provider tenant (Entra ID, ADFS, or another SAML 2.0 / OIDC IdP), not as a VirtualDojo-local credential. VirtualDojo AI CRM authenticates agency users exclusively via federated SSO (SAML 2.0 Web Browser SSO, with OIDC also supported) — see Authentication and Federation Procedures Section 9 for the full federation architecture. There is no username/password login path for agency accounts.
2. Complete federation onboarding once per agency tenant (VirtualDojo configures your IdP as a trusted issuer, exchanges SP/IdP metadata, and validates a test authentication). Federation onboarding is coordinated with security@virtualdojo.com and is documented in Authentication and Federation Procedures Section 9.6.1.
3. Within your own IdP, ensure the intended superadmin user is a member of the SAML/OIDC group your agency has mapped to the superadmin role during onboarding (see the groups claim mapping in Authentication and Federation Procedures Section 9.4). Role assignment is driven by your IdP group membership, not by a separate VirtualDojo user-management step — this means your agency's own access-approval workflow for that group is what actually grants superadmin.
4. Require your IdP to enforce phishing-resistant MFA (FIDO2 security key or PIV/CAC certificate-based authentication) for any account in the superadmin-mapped group. VirtualDojo cannot enforce a stronger authenticator than what your IdP asserts, so this step is the customer's responsibility — see Section 3 of this guide and Section 4 (Conditional Access baseline) for the specific policy to apply.
5. On first successful federated sign-in, VirtualDojo provisions the account via Just-In-Time (JIT) provisioning and assigns the role indicated by the groups claim. If no group claim maps to superadmin, the account is provisioned at the most restrictive role (Read-Only) and must be manually elevated — VirtualDojo will not silently grant top-level access to an unmapped account.
6. Verify the new superadmin account by having it sign in and confirm it can reach Tenant Settings → Administration in the application UI. Record the verification in your agency's onboarding checklist.

2.3 Decommissioning a Top-Level Administrative Account

1. Remove the user from the superadmin-mapped group in your own IdP. This is the primary and immediate control — the next time VirtualDojo re-validates the SAML/OIDC session or the user's assertion is re-issued, the elevated role claim is gone.
2. Revoke the user's active session at the IdP (e.g., Entra ID "Revoke Sessions") so any live token cannot continue to assert the old group membership until natural expiry.
3. Notify security@virtualdojo.com so VirtualDojo can confirm the UserSSOConnection record's is_active flag is set to false if the user is leaving the agency entirely (as opposed to only losing superadmin scope).
4. If the departure is involuntary or security-relevant, treat it as an incident per your agency's own process and notify VirtualDojo immediately rather than waiting for the next scheduled access review — VirtualDojo's quarterly non-organizational user access review (Authentication and Federation Procedures Section 9.6.2) is a backstop, not a substitute for prompt customer-side deprovisioning.
5. Confirm decommissioning by reviewing the tenant's admin audit log (Section 6) for the role-removal event and confirming no further sign-ins occur from that account.

2.4 Security-Relevant Settings Gated to superadmin

The following settings can only be viewed or changed by a superadmin account. Each carries a security implication an agency should understand before changing it:

2.5 Security-Relevant Settings Available to Privileged (admin) Accounts

admin accounts are privileged but scoped: they manage day-to-day tenant operation without the tenant-wide authority described above.

---

3. Required MFA for Administrative and Privileged Accounts

VirtualDojo AI CRM does not offer a local username/password login for agency users — every sign-in is federated through the agency's own IdP (Section 2.2), and MFA enforcement for superadmin and admin accounts is therefore primarily your IdP's responsibility, with VirtualDojo enforcing a floor:

• VirtualDojo-side floor: the application requires the incoming SAML/OIDC assertion to assert that the authentication event included a multi-factor authentication context (authnContextClassRef such as SmartcardPKI for PIV/CAC, or an equivalent multi-factor claim). Assertions that do not assert MFA are still accepted for authentication but the session is flagged and step-up MFA is required before any superadmin- or admin-gated action can be performed.
• Customer-side requirement: your agency's Conditional Access (or equivalent) policy must require MFA for every sign-in to the VirtualDojo AI CRM enterprise application, with no exclusions for the superadmin-mapped group. VirtualDojo recommends the following priority order for the MFA method itself, consistent with OMB M-22-09 phishing-resistance guidance:

If your agency cannot demonstrate AAL2-equivalent MFA enforcement during federation onboarding, VirtualDojo will not activate the federation trust until it is remediated (Authentication and Federation Procedures Section 11.5.2).

---

4. Entra Conditional Access Baseline (For Entra ID Customers)

Most current VirtualDojo AI CRM agency tenants federate from Microsoft Entra ID. If your agency uses Entra ID as its IdP, verify the following Conditional Access baseline is applied to the VirtualDojo AI CRM enterprise application before onboarding any superadmin or admin account. These are the same baseline settings VirtualDojo itself applies to its own Entra ID tenant for administering the platform (Identification and Authentication Policy, Access Control Policy), offered here as the recommended customer-side configuration:

4.1 Policy: Require MFA for All Users

• Assignment: All users, all cloud apps (or scoped to the VirtualDojo AI CRM enterprise application at minimum)
• Grant control: Require multi-factor authentication
• Session control — sign-in frequency: 12 hours maximum for "remember MFA" on compliant devices; do not set to "never expire"

4.2 Policy: Require Phishing-Resistant MFA for Privileged Roles

• Assignment: Users in the group mapped to VirtualDojo superadmin (and recommended for admin)
• Grant control: Require authentication strength = "Phishing-resistant MFA" (FIDO2, Windows Hello for Business, or Entra CBA)
• Session control: 1-hour maximum session lifetime for this group, consistent with VirtualDojo's own internal policy for privileged roles (Access Control Policy, Section AC-4.10)

4.3 Policy: Device Compliance for Administrative Access

• Assignment: Users in the superadmin/admin-mapped groups
• Grant control: Require device to be marked as compliant (Intune or equivalent MDM) — managed, encrypted, up to date
• Rationale: prevents privileged sign-in from an unmanaged personal device even if credentials and MFA are otherwise valid

4.4 Application-Level Session Controls (VirtualDojo-Enforced)

Independent of whatever your IdP's session-frequency policy is set to, VirtualDojo AI CRM enforces its own session ceiling so that a long-lived IdP session cannot translate into an indefinitely long application session:

VirtualDojo recommends agencies leave the Entra ID sign-in-frequency setting at or below 12 hours for standard users and 1 hour for privileged roles even though the application enforces its own tighter ceiling — defense in depth means a compromised or misconfigured application session control should not be the only backstop.

---

5. Network Access Restrictions

VirtualDojo AI CRM is an internet-facing SaaS application (https://app.virtualdojo.com) — there is no customer-managed network perimeter in front of it in the traditional sense, but the following customer-configurable restrictions are available:

VirtualDojo does not offer customer-managed WAF rule authoring or a customer-facing firewall console — the application-layer allow-list above is the supported network restriction mechanism. Agencies requiring network-layer controls beyond this should implement them at their own egress point (e.g., forcing all agency traffic to VirtualDojo through an agency-managed proxy/VPN and then allow-listing only that egress range).

---

6. Audit Logging Configuration Available to Customers

VirtualDojo AI CRM logs authentication events, privileged actions, role changes, and data export/access events to an application-level audit log, which is layered on top of VirtualDojo's own GCP Cloud Logging pipeline (400-day retention at the platform level, per Customer Responsibility Matrix AC-2(12)). Customer-facing configuration options:

VirtualDojo recommends weekly review of the audit log at minimum, and provides a standardized checklist your reviewer can adapt — see Audit Log Review Checklists for the schedule and check items VirtualDojo's own ISSO uses internally (daily/weekly/monthly cadence, specific things to look for such as new-IP logins, privilege escalation events, and bulk data export).

---

7. Secure Defaults (SCG-CSO-SDF)

This section states plainly what ships secure out of the box for a newly onboarded tenant, versus what requires active customer configuration. Nothing in the "customer must configure" column is unsafe left alone — it simply is not something VirtualDojo can set on the customer's behalf because it depends on the customer's own IdP or organizational policy.

7.1 Ships Secure by Default (No Customer Action Required)

7.2 Requires Active Customer Configuration

7.3 Verifying Secure Defaults Are in Place

Use this checklist during onboarding and at each annual access review:

1. Confirm no local username/password authentication path exists for your tenant (attempt to reach a non-federated login form for app.virtualdojo.com — none should be reachable).
2. As superadmin, navigate to Tenant Settings → Administration → Security and confirm the session lifetime and idle timeout fields show 8 hours / 15 minutes or a customer-tightened value — never a value greater than the platform ceiling (the UI will not accept a looser value).
3. Review the Users list and confirm no account holds superadmin or admin that is not mapped through your IdP's group claims (Section 2.2, step 3) — every privileged account should trace back to an entry in your own IdP's group membership, not a VirtualDojo-local grant.
4. Pull a sample of recent JIT-provisioned users from the Audit Log and confirm each was provisioned at Read-Only pending review, not at an elevated role.
5. Confirm TLS 1.0/1.1 are not negotiable against app.virtualdojo.com (e.g., nmap --script ssl-enum-ciphers or an equivalent external scanner) — this should always fail to downgrade regardless of tenant configuration.
6. Document the verification results in your agency's own onboarding or annual review record.

---

8. Getting Help

---

9. Enhanced Capabilities Roadmap (SCG-ENH-*, Not Yet Implemented)

The FedRAMP 20x Consolidated Rules define a set of optional, enhanced-capability SHOULD items beyond the baseline Secure Configuration Guide requirements. VirtualDojo does not currently implement any of the following. They are listed here for transparency and roadmap visibility only — none of the capabilities below exist in the product today, and this guide will be updated (with a version bump, see the document metadata table) if and when any of them ship.

Questions or feature requests related to this roadmap can be sent to security@virtualdojo.com.

---

Document Revision History