Secure configuration guide

Scope

This guide meets the FedRAMP Secure Configuration Guide rule SCG-CSO-RSC. It covers how to securely access, configure, operate and decommission top-level administrative accounts, and explains the security-related settings that only top-level and privileged accounts can change.

• Applies to: Knocknoc Cloud and self-hosted Knocknoc servers.
• Customer responsibility: your identity provider (IdP), MFA policy, the firewalls and load balancers Knocknoc orchestrates, and log retention.
• Version: 1.0. Changes to recommended defaults are recorded in the Change history at the end of this page.

Account types

Knocknoc has two entirely separate authentication domains, Users and Admins. For Users, these can include more than one IdP, with Admins restricted to one single IdP. Users and the User application has no administrative rights nor capability, and Admins can't be granted Knocs (access), which keeps administration separate from access. FedRAMP's top-level administrative and privileged accounts are therefore both Admins in Knocknoc. Non-person privileged credentials, such as firewall API keys and EDL secrets, are covered under Privileged credentials and integrations.

Account type	Knocknoc name	What it controls	Authentication	Count
Admin SSO	Admin	The admin portal (/admin): Settings, Knocs, integrations, agents, users, groups and manual access	Admin SAML with IdP MFA	As needed by organisation
Initial administrator	knocknoc-admin	Same as Admin; created on first start with a random password	Local password, TOTP onboard	Zero. Delete once Admin accounts created
Admin local	Local Admin, for example john-breakglass-admin	Same as Admin; for use only when the IdP is unavailable	Local password + 2FA (TOTP)	2 at most 3, or suited to your org size/standards
User local	User	Requests just-in-time access to Knocs their groups allow	User SAML with IdP MFA	Any

Top-level administrative accounts

Admin rights should come from an IdP group, never from individually created local accounts.

Access

1. Sign in only through Admin SAML, from a managed, compliant device.
2. Require phishing-resistant MFA at the IdP (PIV/CAC or FIDO2) for the Knocknoc admin group.
3. Restrict admin sign-in to approved source IP ranges, such as admin networks or jump hosts. For further isolation, set an Admin portal URL (Admin SAML > Advanced SAML configuration) and allow that hostname only from those ranges.
4. Use a dedicated admin identity, separate from the person's everyday account where your IdP supports it.

Configure (initial provisioning)

1. Sign in as knocknoc-admin. Its password is in the Licensing Portal (Knocknoc Cloud) or the server installer on first start (self-hosted).
2. Install an agency-trusted TLS certificate and set the Public URL (self-hosted).
3. Configure Admin SAML and User SAML (see Authentication) and confirm with Test SAML and Test SAML group.
4. Create the break-glass local Admin with 2FA enabled.
5. Delete knocknoc-admin.
6. Enable SAML-only mode for users if only SSO is required. It applies to users only, so the break-glass local Admin can still sign in.
7. Configure log forwarding before granting any user access.

Operate

• Admins can't be granted Knocs. Give each admin a separate user account for their own network access.
• Review the admin list and Recent Activity (Identities > Admins) at least quarterly and on every role change.
• Watch the certificate expiry shown in Settings > Authentication, and reload IdP metadata after IdP certificate changes.
• Keep the server and agents current on the stable channel; avoid the Beta channel in production.
• Keep server and agent clocks synced with NTP, because SAML and TOTP both depend on accurate time.
• Protect server backups as sensitive data: they contain configuration and secrets.

Decommission

1. Remove the person from the IdP admin group. Knocknoc re-checks group membership on every sign-in and refuses them at their next attempt.
2. Delete their Admin account in Knocknoc. Losing the group blocks sign-in but leaves the account in place, and predefined admins must be deleted directly.
3. Rotate secrets they could see: break-glass password and TOTP, EDL secrets, firewall API keys and Knocknoc API keys.
4. Confirm the removal in the logs and keep the record per your retention policy.

Authentication

SAML for all users and administrators

1. Under Admin > Settings > Authentication, configure User SAML and Admin SAML separately. Use your IdP's metadata URL so signing certificates stay current.
2. Send a stable NameID and the groups attribute. Optionally send sessionDuration (default 420 minutes) and sessionLimit to cap session length and concurrent sessions.
3. Under Admin provisioning, use Predefined SAML Admins or Admins assigned to a SAML group, with a dedicated admin group that no user group shares.
4. Enforce MFA at the IdP for every user, and phishing-resistant MFA for the admin group.
5. Run Test SAML and Test SAML group, then enable SAML-only mode to disable local user logins if only SSO is required. SAML-only mode covers users only: local Admins, including break-glass, can still sign in, so protect them with 2FA and IP restrictions.
6. If you use several user IdPs, scope each Knocknoc group to its provider rather than matching any provider.

With SAML, onboarding, offboarding, MFA and lockout policy are enforced centrally by your IdP, and Knocknoc access ends when the IdP account is disabled.

TOTP for break-glass local admins

• Keep one break-glass local Admin (two at most), named so it stands out in logs, for example breakglass-admin-john-smith.
• Enable 2FA on it so every sign-in needs a TOTP code.
• Use a long, unique passphrase; Knocknoc's zxcvbn strength check rejects guessable passwords. Store the password and the TOTP seed separately in your vault, under dual control.
• Apply the same admin IP restrictions to it as to SAML admins.
• Alert your SOC on every break-glass sign-in and review the session afterwards. Rotate the password and TOTP after each use, and test the account at least quarterly.

Manual access is the network-level break-glass: an Admin grants a single IP address 20 minutes of access to a Knoc. Use it only for lockout recovery, grant the narrowest IP, and record the reason.

Privileged credentials and integrations

Admins manage these credentials and settings. They control the firewalls and load balancers Knocknoc orchestrates, so protect them as privileged access.

Setting	Recommended	Security implication
EDL protection (if EDLs are used)	Secret based on every Allowlist/EDL Knoc; encrypt the secret with the lock after storing it in your vault	IP-only protection leaves the list readable by any host in the allowed range, revealing who has access.
EDL IP restrictions	Only the consuming firewalls' addresses (Knocs > your Knoc > EDL Security)	The default allows the entire IPv4 and IPv6 internet.
HTTPS to orchestrated firewalls	CA-issued certificates on firewall management interfaces; don't use Unsigned certificate or Skip TLS verification	Without certificate validation, an interceptor can capture the firewall API key or alter grants.
Firewall retrieval of EDLs	A certificate profile on the firewall that validates the Knocknoc server certificate	Stops the firewall accepting a spoofed allowlist.
Firewall API accounts	A dedicated account per integration with the minimum role, for example only User-ID Agent (XML API) for Palo Alto Active mode	An over-privileged key can change any firewall policy if the agent is compromised.
Integration mode	Prefer Active (API) integrations; use EDLs where polling or data-diode designs require them	Active mode needs no EDL secret, and grants and revokes apply immediately.
Tags and objects	One tag per Knoc; run Validate integration before saving	Shared tags let one Knoc remove another's users; validation catches misconfiguration.
Grant duration and click-to-grant	Shortest workable grant; Require click to grant and TOTP per Knoc for sensitive services	Longer grants keep firewall openings in place after the user has finished.
Groups	Mirror IdP groups, scoped to their provider; no catch-all groups	Mis-mapping grants network reach to the wrong people.

Logging and monitoring

Forward Knocknoc logs to your SIEM with the GELF listener over tls://, and alert on the events below.

• Any break-glass or local Admin sign-in, and any use of knocknoc-admin
• Changes to authentication, admin provisioning, log forwarding or agentic access settings
• Manual access grants
• New or changed integrations, EDL secrets and API keys
• Repeated failed sign-ins or access requests

Retain logs per your agency's policy (for example OMB M-21-31) and review admin activity at least monthly.

Secure configuration checklist

• User SAML and Admin SAML configured from IdP metadata URLs
• Phishing-resistant MFA enforced at the IdP for the admin group
• Admin provisioning limited to one dedicated group of 2 to 3 people, or a predefined list
• Admin sign-in restricted to approved IP ranges, or a Knoc configured for web-app sudo
• knocknoc-admin deleted
• Local user login disabled (SAML-only) where only SSO is required
• One break-glass local Admin with 2FA, vaulted under dual control and tested quarterly
• Every EDL secret-protected and restricted to consuming firewall IPs
• Firewall integrations use CA-validated HTTPS and least-privilege API accounts
• Agentic and Companion Access off unless approved; GreyNoise enabled
• Logs forwarded over tls://, debug mode off, alerts on admin and break-glass activity
• Admin list and Recent Activity reviewed quarterly

Change history

Version	Date	Change
1.0	November 2026	First publication, aligned to FedRAMP SCG-CSO-RSC

Sources

• FedRAMP Consolidated Rules for 2026: Secure Configuration Guide
• Knocknoc docs: Settings, Admins, SAML, Local Authentication, Allowlist (EDLs), Palo Alto, Break Glass