Architecture as Security
Security is not a feature—it's a foundation. We combine hardware isolation, cryptographic sharding, and verifiable execution to eliminate single points of failure.
Last updated: January 2026
Openfort provides two core services — authentication and wallets. In wallets, the security question is simple: who can produce a signature?
This page explains custody and security as enforced by architecture, not by promises. It covers what is always true, what is configurable by developers, and what end users must do to keep security guarantees intact across OpenSigner and Backend wallets.
1. Security Backbone
Security is strongest when it’s enforced by the system design: isolate sensitive execution, remove single points of failure, and make authority explicit.
1.1 Threat model
- Infrastructure compromise (servers, cloud, operator access)
- Credential theft / replay attempts
- Key leakage to logs, disk, or caches
- Insider misuse and privilege escalation
- Misconfiguration risk (over-broad permissions, missing consent, weak policies)
1.2 Three pillars
- Isolated execution for signing: sensitive signing operations are designed to run in an isolated environment, so key material does not need to be exposed to application servers during signing.
- Key sharding: embedded wallet keys are split into shares so no single party or system controls the full key material.
- Auth + policy enforcement: signing requires authenticated authorization and can be constrained by developer-configured policies (scoped permissions, expiries, limits).
1.3 Defense in depth
The goal is to make attacks require multiple independent failures: a compromised server, stolen credentials, or a leaked share should not be enough on its own to expand signing authority beyond what was configured and approved.
2. Scope of Services
Openfort provides two core services:
- Authentication: establishing user sessions and authorization context.
- Wallet infrastructure: embedded wallets (OpenSigner) and backend wallets (TEE-based), including signing orchestration depending on configuration.
What's outside Openfort's control includes third-party apps users interact with (DApps and DEXs), chain and network security, and developer-controlled application security (backend, consent UX, policy configuration).
3. From Login to Signature
In practice, “custody” is enforced by a lifecycle: authenticate, authorize, constrain, then sign inside the security boundary.
3.1 Authenticate
- User authentication establishes a session and authorization context.
- Developers can require step-up authentication for sensitive flows (for example, re-auth or MFA).
3.2 Authorize
- Requests are evaluated against application policies and permissions.
- Delegated actions (session keys) should be scoped: expiry, limits, and allowed actions.
3.3 Orchestrate key material
- Only after authorization, the required shares and approvals are orchestrated.
- Key shares are designed so that no single share is sufficient to sign.
3.4 Sign
- Signing is designed to occur inside Openfort’s signing boundary, producing signatures without exporting private keys.
- Developers can layer additional approvals for high-risk transactions.
3.5 Broadcast & audit
- Transactions are broadcast using configured infrastructure (for example, RPC providers).
- Relevant events can be logged for auditing and incident response (auth, policy, and signing).
4. Wallet Deployments & Authority
Openfort supports multiple wallet configurations. What matters is authority: who is the owner, who can sign, and what constraints are enforced.
4.1 Embedded Wallets
- What it is: wallets for end users; users may also connect an external wallet depending on integration.
- Owner (authority root): the end user.
- Who can sign: authenticated user-approved flows, constrained by policies.
- What’s enforced: key shares are distributed so no single party controls the full key material.
- Configurable: quorum keys, session requirements, and recovery modes.
4.2 Backend Wallets
- What it is: wallets for app-controlled flows (for example, treasury, automation, and ops).
- Owner (authority root): the developer or organization (not an end user).
- Who can sign: server-side flows governed by org policies and approvals.
- What’s enforced: signing is designed to run within the TEE signing boundary, with policy and approval checks depending on configuration.
- Configurable: roles, spending limits, and allowlists.
4.3 Delegated Actions
- What it is: a user delegates limited signing authority for a specific purpose (for example, recurring actions) via session keys.
- Owner vs signer: the user remains the owner (can revoke or expire delegation); the developer or system becomes a signer within a defined scope.
- Constraints: delegations should be scoped (expiry, caps, and allowed actions).
- Developer obligations: clear disclosures and explicit user consent, plus revocation UX.
Implication: Delegation expands who can sign. Whether a setup is “self-custodial” depends on how delegation scope, approvals, and consent UX are configured. Openfort provides the primitives; developers define the constraints and user experience.
5. Key Material & Recovery
5.1 Entropy / “Secret”
Wallet creation involves entropy-derived key material. Depending on configuration, users may be responsible for safeguarding user-held factors (device-based shares, recovery codes, passkeys) that are required to maintain or recover access.
5.2 Key shares (not a single key)
Openfort is designed around shares and authorization: embedded wallet keys are split into shares across trust domains, and signing requires the right combination of shares and approvals. No single share should be sufficient to sign on its own.
If Openfort stores encrypted key material or an auth share, that material is treated as sensitive, protected with confidentiality controls, and designed to be insufficient on its own to authorize signing.
5.3 Openfort access limitations (architectural)
Openfort is designed to prevent unilateral signing by Openfort alone by combining: key sharding, authenticated authorization, and a signing boundary that produces signatures without exporting private keys.
Note: If user-held credentials or device shares are lost, recovery depends on the recovery mode configured by the developer.
5.4 Recovery modes
- User-held recovery: recovery requires user-held factors; losing them may be unrecoverable.
- Automatic recovery (if configured): recovery assistance may be available when explicitly configured by the developer, often requiring additional approvals or constraints.
6. Progressive Security Controls
Strong security shouldn’t always mean friction. Progressive security scales controls with risk: step up verification for sensitive actions, keep low-risk flows fast, and constrain delegation.
Controls (primitives)
- Policy constraints (allowed actions, expiries, and limits) depending on integration.
- Delegation via session keys with explicit scope.
- Optional step-up authentication or approvals for high-risk actions (where implemented).
- Audit and reporting hooks for security operations and forensics.
Recommended patterns
- Short-lived permissions with easy revocation.
- Spending caps and allowlists for delegated actions.
- Step-up auth (re-auth or MFA) for withdrawals and high-value transfers.
8. Audit Readiness & Incident Response
8.1 Security reporting
If unauthorized or suspicious activity is detected related to wallets or linked accounts, report it immediately via security@openfort.io.
8.2 Monitoring & response
- Operational monitoring for authentication and signing infrastructure.
- Incident triage and containment playbooks designed to reduce blast radius.
- Emergency controls may include revoking sessions, tightening policies, and disabling specific pathways depending on the integration and configuration.
Note: The specific set of emergency controls can vary based on the product, deployment model, and developer configuration.
8.3 Audits & security reports
- Openfort provides audit reports and security documentation for customers and partners.
- View available audit materials in the Trust Center sidebar (“View Audit Reports”).
- OpenSigner is open source; you can review the repository linked in the sidebar.
9. Platform Abuse
Openfort strictly prohibits attempts to obtain another user’s credentials or other security information, bypassing access controls, cracking passwords or encryption codes, attacking signing systems, or otherwise jeopardizing the security of wallets and accounts.
10. Third-Party Dependencies
Openfort's Services may depend on third-party APIs and services (including open source components), and users may interact with third-party apps (for example, DApps and DEXs) using wallets.
- Outside Openfort control: third-party dApps, chain and network behavior, and the security posture of developer applications.
- Shared surface: infrastructure providers used to operate services (availability, networking, and runtime environments).
- Developer-controlled: backend services, consent UX, session and key handling, allowlists, spending limits, and security monitoring at the application layer.
11. Security FAQ
Can Openfort move user funds?
Openfort is designed to prevent unilateral signing by Openfort alone: embedded wallets use sharded keys, signing is gated by authentication and policy, and sensitive signing operations are performed within a signing boundary.
If a developer enables Delegated Actions, the developer or system can sign within the explicit scope granted by the user (for example, limits, expiries, and allowed actions).
What happens if my Secret or credentials are lost?
Recovery depends on the configured recovery mode. If the setup relies on user-held factors (device shares, passkeys, recovery codes), losing them may be unrecoverable.
Some integrations may support “automatic recovery” workflows if explicitly configured by the developer, typically with additional approvals or constraints.
Who can sign in Delegated Actions?
A developer or system signer can sign within the explicit scope of the delegation (for example, time bound, spending caps, and allowed actions). Users can revoke delegations when no longer needed.
Where does signing happen?
Signing occurs inside Openfort's signing boundary. For Backend wallets, this is commonly implemented as an isolated execution environment (TEE). For Embedded wallets, signing is gated by the required combination of shares and approvals in the iframe. The output is a signature—not exported private keys.
What would an attacker need to compromise to sign without consent?
The design goal is that compromising a single layer is insufficient. An attacker would typically need multiple independent failures (for example, credentials, overly permissive policies, and sufficient shares and approvals) to expand signing authority beyond what was configured and approved.
Is everything always "self-custodial"?
Embedded wallet deployments are typically user-centered in authority. Backend wallets are usually org-controlled by design. Delegation can change who can sign, so the custody properties of a specific integration depend on scope, approvals, and the consent experience implemented by the developer.