Secure Configuration Guide

1. Scope and applicability

This guide applies to the Boundera platform delivered as software-as-a-service (the cloud service offering). It explains how to securely configure and operate the administrative accounts that control access to the offering, and describes the security-relevant settings those accounts govern.

Within Boundera, a customer's enterprise-wide access to the entire offering is controlled by the Organization Owner account. Two further account types carry elevated privilege and are addressed here as privileged accounts: the Organization Member and the external Assessor.

This guide does not cover self-managed or self-hosted installations of Boundera; those deployments are outside the authorized service boundary and are administered entirely by the operator who runs them.

It is published to address the FedRAMP 2026 Consolidated Rules Secure Configuration Guide requirements:

• OFR-AFR-SCG — follow and persistently address the Secure Configuration Guide rules.
• SCG-CSO-RSC — provide recommendations for securely accessing, configuring, operating, and decommissioning top-level administrative accounts, and explain security-relevant settings and their implications.
• SCG-CSO-AUP — explain how to obtain and use this guide.
• SCG-CSO-PUB — make this guide publicly available.
• SCG-CSO-SDF — apply secure defaults when accounts are first provisioned.

2. Top-level administrative account: the Organization Owner

The Organization Owneris the highest-privilege account within a customer organization and is the top-level administrative account for that organization's use of Boundera. The first person to register an organization becomes its Organization Owner; additional Owners can be added by an existing Owner through an invitation.

An Organization Owner can:

• Create and manage the systems (customers) tracked under the organization.
• Invite members, assign roles, and remove members.
• Configure single sign-on (SSO) for the organization and require it for a domain.
• Manage credentials for connected cloud accounts and tools.
• Enable or disable the organization's public Trust Center.

Because this account controls enterprise-wide access, the guidance below concentrates on protecting it. Organization Members hold day-to-day access within the organization but cannot manage members, SSO, or systems; Assessors receive time-limited, per-system access for independent review.

3. Securely accessing administrative accounts

Boundera supports the following authentication factors:

• Passkeys (FIDO2 / WebAuthn) — phishing-resistant hardware- or platform-bound credentials. Recommended as the primary factor for every Organization Owner.
• Time-based one-time passwords (TOTP) from an authenticator app, with single-use recovery codes for backup.
• Single sign-on (SSO)through your organization's identity provider via OpenID Connect.
• Email sign-in link, where enabled for the deployment.

Authenticated sessions are carried in HttpOnly, Secure cookies that are not readable by page scripts and are protected against cross-site request forgery. Access tokens are short-lived and refresh tokens rotate, so a session can be revoked promptly.

Recommended access hardening for Organization Owners:

• Register a passkey for every Owner. Boundera requires Organization Owners to enroll a strong authentication factor and prompts enrollment at sign-in.
• Connect your identity provider and enforce SSOfor your email domain so administrator sign-in follows your provider's multi-factor and conditional-access policies.
• Keep recovery codes offline and treat them as secrets.

4. Configuring security settings and their implications

The following settings are controlled by the Organization Owner. Each is listed with its security implication so you can make an informed configuration choice.

• SSO connection and enforcement. Configure an OpenID Connect connection for your email domain, then require it. Implication: centralizes authentication and MFA under your identity provider. Until enforcement is turned on, password and email-link sign-in remain available as a fallback.
• Strong-factor enrollment for Owners. Owners are required to register a passkey or TOTP authenticator. Implication: protects the highest-privilege accounts against stolen or reused passwords.
• Member roles and least privilege. Invite people as Organization Members (the default) and grant the Owner role only when enterprise-wide administration is genuinely required. Implication: limits how many accounts can change organization-wide settings.
• Connected credentials. Credentials for connected cloud accounts and tools are encrypted at rest and are never returned by the API after they are entered. Rotate them from the connector settings. Implication: keeps third-party secrets confined and rotatable.
• Trust Center publication. Publishing your Trust Center exposes selected compliance information at a public URL; it is disabled by default. Implication: you decide what, if anything, is shared publicly.

5. Secure defaults at provisioning

A newly provisioned organization starts in a secure-by-default posture:

• New members receive the least-privileged Organization Member role; only the initial account that creates the organization is an Owner.
• The public Trust Center is disabled by default — no data is exposed publicly until you explicitly enable it.
• Organization Owners are required to enroll a strong authentication factor.
• Platform secrets — session-signing keys, connected credentials, and MFA seeds — are generated securely and stored encrypted; the platform will not start in production without a strong signing key.
• All access to the platform is over TLS (HTTPS).

6. Operating administrative accounts securely

• Sessions. Access tokens expire after a short interval; refresh tokens rotate and prior tokens are invalidated on rotation and at sign-out. Sign out to revoke a session immediately.
• Authentication audit trail. Sign-in, sign-out, token refresh, sign-in-link, and multi-factor events are recorded to an append-only authentication log.
• Rate limiting. Authentication endpoints are rate-limited to slow automated guessing.
• Tenant isolation.Each organization's data is isolated; members operate only within their own organization's systems.
• Periodic review. Review the members list regularly, remove access that is no longer needed, and keep the number of Organization Owners to the minimum required.

7. Decommissioning administrative access

• Removing a member.An Organization Owner removes the member from the organization; the member's active sessions are invalidated.
• Decommissioning or transferring an Owner. Because Owner accounts hold enterprise-wide control, Owner removal and ownership transfer are performed with assistance from Boundera security support to prevent accidental loss of administrative control. Contact security@boundera.io.
• Credential rotation on offboarding. When an administrator leaves, rotate any connected credentials they had access to.

8. Obtaining and using this guide

This guide is published publicly at https://boundera.io/trust/secure-configuration-guideand is referenced in Boundera's FedRAMP Certification Package. It describes the current Boundera software-as-a-service offering.

Configuration questions and requests related to this guide can be directed to security@boundera.io.

9. Enhanced capabilities and versioning

• Programmatic configuration.SSO connections and per-user authentication factors (passkeys and TOTP) are managed through Boundera's authenticated API. The current authentication posture — enabled factors and the Owner strong-factor requirement — is reported by the platform's authentication configuration endpoint.
• Versioning.This guide is versioned. Material changes are reflected in the “Last updated” date below and in the published revision history of this page.

10. Shared responsibility

Boundera secures the platform — encryption in transit and at rest, session security, tenant isolation, patching, and infrastructure hardening.

You secure your administrative accounts and configuration using this guide: enroll strong authentication factors, enforce SSO, apply least privilege, and review access regularly.