Skip to main content

Organization Settings: CORS, JWT, Encryption, and Security Config

Keeptrusts does not put CORS, JWT, encryption, and MFA into one generic admin form: /settings/organisation covers organization identity and related org-level settings, /settings/security covers personal security flows and MFA policy, and deployment-managed controls such as CORS origins, JWT verification keys, secret backends, and key rotation stay in environment configuration where they belong.

Use this page when​

  • You need to understand which security settings belong in the console and which belong in deployment config.
  • You are trying to harden a production environment without inventing a nonexistent UI.
  • You need a practical map for CORS, JWT rotation, MFA policy, and encryption backends.

Primary audience​

  • Primary: Technical Engineers and platform operators owning deployment security
  • Secondary: Technical Leaders responsible for operational hardening

The problem​

Security settings become messy when teams expect every control to live in one place. They open the console, look for a page called "Security," and assume everything from passkeys to JWT key rotation to CORS policy must be editable there.

That is not how the current product is structured, and for good reason.

Some controls are user- or org-facing and belong in the console because operators need to see and change them frequently. Others are deployment primitives. They affect protocol boundaries, key management, and startup behavior. Those belong in environment variables and infrastructure configuration, not in a page anyone can casually click through.

The practical risk is not confusion by itself. The risk is doing nothing because the setting is not where you expected it, or worse, assuming a UI control exists and never hardening the actual deployment path.

The solution​

The easiest way to think about the current model is to split it into three layers.

The first layer is organization identity and governance defaults. That lives on /settings/organisation. This is where operators work with organization-level metadata and related org-owned settings.

The second layer is day-to-day user security. That lives on /settings/security. The current page is focused on passkey or authenticator setup and the organization MFA policy. It is intentionally not pretending to be a full deployment hardening console.

The third layer is deployment-managed security. That includes controls such as:

  • KEEPTRUSTS_CORS_ALLOWED_ORIGINS
  • KEEPTRUSTS_JWT_SIGNING_KID
  • KEEPTRUSTS_JWT_VERIFICATION_KEYS
  • KEEPTRUSTS_SECRET_ENCRYPTION_KEY
  • KEEPTRUSTS_ENCRYPTION_KEY_PREVIOUS
  • KEEPTRUSTS_SECRET_BACKEND
  • backend-specific secret-manager settings such as KEEPTRUSTS_KMS_KEY_ARN, KEEPTRUSTS_AZURE_KEY_VAULT_URL, KEEPTRUSTS_GCP_KMS_KEY_NAME, KEEPTRUSTS_VAULT_ADDR, and KEEPTRUSTS_CYBERARK_URL

This split matches the underlying runtime. GET /v1/settings/security reports session and password settings derived from deployment configuration, while the current console page centers on MFA policy and personal MFA setup. CORS and secret-encryption backends are infrastructure concerns, not ordinary tenant preferences.

Implementation​

The practical hardening workflow is to review the controls in order of ownership.

  1. Open /settings/organisation and confirm organization metadata and any org-level governance defaults are correct.
  2. Open /settings/security and verify the MFA policy matches the environment you are operating.
  3. Review your deployment configuration for the protocol and key-management controls that do not belong in the tenant UI.
  4. Verify that JWT rotation, CORS origins, and secret backend settings are managed in the same infrastructure workflow that owns the rest of your runtime.
  5. After any change, test the real behavior at the edge instead of assuming the configuration is active.

This shell check is a safe way to confirm which deployment-managed controls are actually set without printing secret values:

for name in \
  KEEPTRUSTS_CORS_ALLOWED_ORIGINS \
  KEEPTRUSTS_JWT_SIGNING_KID \
  KEEPTRUSTS_JWT_VERIFICATION_KEYS \
  KEEPTRUSTS_SECRET_BACKEND \
  KEEPTRUSTS_SECRET_ENCRYPTION_KEY \
  KEEPTRUSTS_ENCRYPTION_KEY_PREVIOUS \
  KEEPTRUSTS_KMS_KEY_ARN \
  KEEPTRUSTS_AZURE_KEY_VAULT_URL \
  KEEPTRUSTS_GCP_KMS_KEY_NAME \
  KEEPTRUSTS_VAULT_ADDR \
  KEEPTRUSTS_CYBERARK_URL
do
  if printenv "$name" >/dev/null; then
    printf '%s=configured\n' "$name"
  fi
done

That output is not the end of the job. It is the start of validation. If CORS is configured, confirm the gateway or frontend edge actually responds the way you expect. If JWT rotation keys are set, confirm old sessions validate and new sessions mint with the correct kid. If a non-local secret backend is enabled, confirm the service boots and can decrypt existing encrypted material.

The biggest mistake to avoid is treating UI and deployment security as interchangeable. They are not. MFA policy is an operating setting. JWT verification and secret backend wiring are deployment architecture.

Results and impact​

Teams that understand this split usually harden their environments faster because they stop looking for one page to solve every problem. Operators use the console for the settings the console actually owns. Platform teams use infrastructure config for the settings that define trust boundaries and key material.

That makes both sides cleaner. The UI stays understandable. The deployment remains explicit. Auditors and responders also get a more truthful system map: they can see which controls are tenant-managed and which are environment-managed.

Most importantly, it reduces the risk of false confidence. A control is either in the UI because operators manage it, or in the environment because the runtime depends on it. You do not have to guess where it belongs.

Key takeaways​

  • /settings/organisation and /settings/security are real console surfaces, but they are not a complete replacement for deployment hardening.
  • CORS, JWT verification, key rotation, and secret backends are deployment-managed controls.
  • GET /v1/settings/security reports deployment-derived values even when the console page focuses on MFA policy and user security setup.
  • Validate edge behavior after every security change instead of trusting the setting name alone.
  • Treat UI-owned settings and infrastructure-owned settings as separate operating layers.

Next steps​