Zero Trust Architecture Policy

This policy states how BreathEasy Administrative Services LLC applies zero trust principles to BreathEasy | Ledger, the accounting application published at ledger.breatheasy.net. It is a companion to the Information Security Policy and Procedures, the Access Controls Policy, and the Data Retention and Disposal Policy, and it carries the same authority.

Zero trust means no request is trusted because of where it came from. Being inside a network, holding a session, or having signed in earlier in the day grants nothing on its own. Every request carries an identity, that identity is verified again at the point of use, and the request is allowed only for the specific records that identity owns.

The scope covers the Ledger application and its database, the marketing site, company email and domain accounts, the hosting and database platform, any financial account data received from an aggregator such as Plaid, and the laptops and mobile devices used by anyone with access to production.

This policy describes controls we actually operate. Where a control commonly found in a large enterprise does not apply to a fully managed hosting model, the policy says so plainly rather than claiming coverage we cannot evidence.

• Never trust, always verify. Every request to the application is authenticated on the server. There is no trusted network, no trusted subnet, and no internal caller that skips the check.
• Verify explicitly and continuously. Identity, second factor, device, and session freshness are re-evaluated during a session, not only at sign in.
• Assume breach. The design assumes a credential can be stolen, so a password alone reaches nothing sensitive, and a stolen session is limited by expiry, device binding, and step-up requirements.
• Least privilege by default. A person sees the one workspace they belong to and nothing more. Elevated capability is granted by explicit role, not inherited from a job title.
• Enforce at the data layer. Permission decisions live in the database next to the data, so a mistake in application code cannot expose another customer's records.
• Segment the blast radius. Public pages, the signed-in portal, an individual business workspace, landlord-only functions, and privileged service credentials are separate trust zones with separate controls.
• Record and review. Access, second-step outcomes, new devices, and administrative actions are logged, retained, and reviewed on a schedule.

Identity is the primary control plane. Every account is an individual human account tied to a unique email address. Shared logins are prohibited, and service credentials are never issued to a person.

• Phishing-resistant multi-factor is available to every account and required where this policy says so. Passkeys use WebAuthn and are bound to the site origin, so a lookalike domain cannot replay them.
• Authenticator app codes are supported as the second strong factor. Emailed one-time codes exist as a fallback so nobody is locked out, and recovery codes are single use.
• SMS is deliberately not offered as a factor because it is not phishing resistant and is vulnerable to number porting.
• Passing the second step marks the current browser session as verified for a limited window. When that window ends, the second step is asked for again.
• Sensitive operations require a fresh strong step-up. Connecting or refreshing a bank connection, and viewing a full account number, require a passkey or an authenticator code, never an emailed code alone.
• Password reset is self-service by emailed link, and a reset does not satisfy the second step.

A landlord setting controls how broadly the second step is required: required for every account, required only for accounts with a connected bank, or, for a limited migration window, off. The setting is recorded and reviewed quarterly, and the intended steady state is required for every account.

• Company devices with access to production must have full disk encryption, automatic operating system updates, a screen lock under five minutes, and current endpoint protection. Each device is recorded with its owner and the date its posture was last verified.
• Customer devices are not managed by us. Instead we bind trust to the browser: after a successful second step, a person may choose to remember that browser for thirty days by storing an opaque random token whose hash alone is kept on the server.
• A remembered browser is an identified browser, not an exempt one. It still authenticates every request, still expires, and is still refused for bank-grade actions, which always demand a fresh strong factor.
• Trusted browsers are listed on the Account page with the date added, the browser description, and last use, and can be revoked individually at any time.
• A verified session is bound to the browser fingerprint recorded when it was verified. If that fingerprint changes, the session is treated as unverified and the second step is requested again.

The application runs on fully managed hosting. We do not operate an office network, a VPN concentrator, a corporate firewall, or private circuits, so we do not claim controls of that kind. The network posture we do operate is stated here in full.

• Every connection is served over HTTPS with TLS 1.2 or better, and HTTP is redirected rather than served.
• The database is not exposed to the public internet as an open port for application traffic. Application access is mediated by an authenticated data API that enforces row level policies.
• There is no VPN that grants implicit trust, and therefore no network location that confers access. A person on any network gets exactly the same treatment.
• Administrative access to the hosting and database platform uses provider accounts protected by multi-factor authentication.
• Outbound integrations are limited to a named list of subprocessors published on the security page.

• Server code authenticates every call. Application server functions validate a bearer token on each request and act as that specific user, so the database applies the same policies it would for a direct query.
• Browser code is never trusted to enforce permission. Hiding a button is a convenience; the server refuses the action regardless.
• Privileged service credentials are isolated to server-only modules that cannot be imported into browser code, and they are used only for narrow administrative work after the caller's role has already been verified through their own identity.
• Public endpoints are explicitly separated from authenticated ones and are limited to read-only, non-personal content such as published policy documents.
• Secrets are held in the managed secret store, never in source control, and are read only inside server execution paths.
• Dependencies are reviewed for known vulnerabilities, and the automated security review is run before each publish.

• Data is encrypted in transit with TLS and at rest with AES-256 by the hosting platform. Bank access tokens receive a second layer of application encryption.
• Every table holding customer data carries row level security with policies scoped to workspace membership, so a query issued for one customer cannot return another customer's rows.
• Workspace assignment is written by database triggers from the parent record rather than accepted from the browser, so a client cannot claim a workspace it does not belong to.
• We never receive or store bank usernames and passwords, and connections are read-only. We cannot move money.
• Exports and reports are generated for the requesting user's workspace only, and export actions are recorded in the access event log.
• Retention and disposal follow the Data Retention and Disposal Policy.

Segmentation is implemented in identity and data rather than in subnets, which suits a managed platform and is more resistant to configuration drift. The trust zones are:

Crossing a boundary is never implicit. Moving from the portal into a workspace, or from a workspace into an administrative function, is a new authorization decision made on the server.

• The application records access events including sign in, second-step success and failure, new trusted devices, device revocation, administrative actions, and data exports, with the account, the outcome, the time, and a coarse device description.
• Access events are readable by the account they belong to and by platform administrators, and are retained for twelve months as evidence.
• A notice is emailed to the account owner when a new browser is trusted, so an unexpected addition is visible immediately.
• Repeated failed second steps are treated as a security event and reviewed by the policy owner.
• The automated platform security review runs before each publish, and its findings are tracked to closure in the security program record.
• Access reviews are performed quarterly against the Access Controls Policy, and this policy is reviewed at least annually.

We do not currently operate a twenty-four hour staffed security operations center or a third-party managed detection service. Monitoring is automated collection with human review by the policy owner, which is stated here so a reviewer is not left to assume otherwise.

Exceptions to this policy must be requested in writing, approved by the policy owner, given an expiry date, and recorded in the security program record with a compensating control. An exception is never open ended.

Failure to follow this policy may result in removal of access, termination of an engagement, or termination of employment. For contractors and vendors, it is grounds for immediate termination of the agreement.

This policy is reviewed at least annually, and sooner after a material change to the architecture, a significant incident, or a new regulatory or contractual requirement. The review date, reviewer, and outcome are recorded.