FINMA, BaFin, the EU, NIST, NSA and U.S. government strategies are converging on continuous authorization, Zero Trust, resilience, evidence, accountability and enforceable boundaries. See source by source how immo.quick already unifies these control properties in a deterministic Execution Rights architecture — and where Machine Law goes further.
immo.quick separates access from execution authority. A request must first pass the applicable admission boundary; successful access alone still does not authorize productive effect.
Core places a fail-closed Access Guardian before the governance and compliance pipeline. If any required validation condition fails, the request does not reach the downstream governance logic.
The Serverless Edition requires valid attestation from a registered client at the edge before the request reaches the downstream gate path.
Access is not authority. Productive effect requires a valid, current, scope-bound Execution Right and an executable Capability. For physical state, observation is not authority, consensus is not physical truth, and a valid signature is not verified provenance. Unverified or unresolved provenance remains fail-closed.
Claim Boundary: Only the architecture of the immo.quick Serverless Edition was demonstrably submitted/handed to the BSI on 28 July 2026. Core was not submitted to the BSI. Submission does not constitute BSI audit, certification, recognition or confirmation.
Institutional execution cannot depend on a single valid thing. A valid signature is not enough, a valid proof is not enough, and a valid software artifact is not enough. immo.quick Serverless Edition is built around a layered security model in which cryptographic validity, contextual validity, relational validity, authoritative state validity and collective state coherence must close together before a critical execution path can become possible.
The result is a security architecture designed to prevent trust from concentrating in one algorithm, one signing root, one proof, one build artifact, one compute instance, one witness or one threshold participant. The architecture remains fully serverless and hardware-independent: hardware may execute cryptographic operations, but hardware does not create authority and no HSM, TEE or proprietary hardware root is required to define system trust.
Cryptographic validity is necessary. Contextual validity is necessary. Relational validity is necessary. Authoritative state validity is necessary. None is sufficient alone.
Post-quantum cryptography is already integrated into the execution and evidence architecture rather than being treated as a future migration note. Algorithm lifecycle and cryptographic policy transitions remain versioned so that cryptographic change can be introduced without rewriting historical evidence.
The public claim is deliberately precise: the system is designed to reduce dependence on any single cryptographic assumption and to preserve evidence continuity across cryptographic policy transitions. immo.quick does not claim that a complete software system is ‘unbreakable’ or that post-quantum primitives eliminate every implementation, execution-state, authority or supply-chain risk.
The current baseline has been subjected to compound adversarial regression scenarios covering proof and build substitution, distributed-state manipulation, threshold-context poisoning, authority-scope misuse, participant-set drift, witness split-brain and stale capability binding.
Security findings are not deleted from the architecture history. A discovered collective-state weakness in the MPC reconstruction path was retained as a permanent finding, remediated, converted into a broader system invariant and bound to regression verification. That policy is intentional: security maturity is better demonstrated by preserved findings, proven remediation and repeatable regression than by a claim that no weakness has ever existed.
The baseline binds the required cryptographic, proof, build, deployment, distributed-execution, threshold-computation, adversarial-test and remediation state into a versioned security reference. After sealing, a security-critical change is either identical to the baseline or must appear as a new authorized and provable state.
View Fortress Baseline 1.2.0 →Regulators, institutional clients, auditors, strategic partners and qualified investors can request deeper review, while exact protocol bindings, state-transition logic, threshold topology, internal proof structures and the sealed definitive baseline remain controlled and, where required, NDA-governed.
View the disclosure process →Positioning by audience: institutions, regulators, CISOs, investors →
For institutions that need to understand not only what the system claims, but how security-critical execution is made provable, immo.quick provides a structured technical review process with disclosure depth matched to the role and purpose of the requesting party.