PrimeBrickPrimeBrick
  • Docs
  • Contact
  • MIT License
  • Documentation
  • MCP Server
  • API Catalog
  • Services
  • Libraries
PrimeBrickPrimeBrick

© 2026 PrimeBrick. MIT License. v3.8.0

github
Getting Started
Compliance & Policy
    Automated Compliance AssessmentAuthentication & MFASecurity Posture & Step-Up AuthenticationGDPR & Data ProtectionISO 27001 & Security StandardsVPAT 2.5 INT — Accessibility Conformance Report
API Reference
powered by Zudoku
Compliance & Policy

Security Posture & Step-Up Authentication

Overview

Primebrick enforces a strict security posture: every critical action — changing a user password, modifying RBAC permissions, altering security settings — requires an in-app security guard with admin re-login and MFA verification. No session reuse, no silent elevation.

In-app security guard

When a user attempts a critical action, the Primebrick Frontend opens an in-app modal that requires:

  1. Admin credentials: The user must re-enter their password
  2. MFA verification: A fresh MFA challenge (TOTP, hardware key, or passkey)

No action proceeds without fresh verification. This prevents session hijacking from being sufficient to perform destructive operations.

Critical actions that require step-up

ActionWhy it's critical
Change user passwordAccount takeover vector
Modify RBAC permissionsPrivilege escalation
Alter security settingsCould weaken the system
Delete organizationIrreversible data loss
Manage API keysCredential management
Modify identity provider configAuthentication bypass risk

Step-up authentication (NIST SP 800-63B)

Following NIST SP 800-63B, sensitive operations require a fresh authentication event, not just an existing session. This is known as step-up authentication or re-authentication.

The existing JWT/session token is insufficient for critical actions. A new MFA challenge is always required, and the resulting step-up token has a short lifetime (typically 5 minutes) and is scoped to the specific action being performed.

How it works

  1. User clicks a critical action (e.g., "Delete organization")
  2. Frontend opens the security guard modal
  3. User enters credentials + completes MFA challenge
  4. Backend issues a step-up token (short-lived, action-scoped)
  5. Frontend sends the step-up token with the critical action request
  6. Backend validates the step-up token before executing the action
  7. Step-up token is consumed — it cannot be reused

OWASP ASVS alignment

Primebrick's security posture meets OWASP Application Security Verification Standard (ASVS) V3.4 — session management requirements for high-value transactions:

  • V3.4.1: Step-up authentication for high-value transactions
  • V3.4.2: Re-authentication before sensitive operations
  • V3.4.3: Step-up token has limited lifetime and scope

No session reuse

Existing JWT/session tokens are insufficient for critical actions. Even if an attacker steals a session token, they cannot perform critical operations without completing a fresh MFA challenge. This significantly reduces the blast radius of session theft.

Standards & references

StandardRelevance
NIST SP 800-63BStep-up authentication requirements
OWASP ASVS V3.4Session management for high-value transactions
OWASP Top 10A07:2021 — Identification and Authentication Failures
CIS Controls v8Control 6 — Access Control Management
Last modified on July 26, 2026
Authentication & MFAGDPR & Data Protection
On this page
  • Overview
  • In-app security guard
    • Critical actions that require step-up
  • Step-up authentication (NIST SP 800-63B)
    • How it works
  • OWASP ASVS alignment
  • No session reuse
  • Standards & references