Protecting your data

• Invite-only — there is no public sign-up route.
• Credentials are handled by Supabase Auth. Office accounts sign in with an email address; factory-floor accounts sign in with a username, because they have no inbox. We never store or see a password ourselves.
• Time-based one-time password (TOTP) multi-factor authentication is available on every account. Once it is enrolled, a session that has not answered the challenge is served no protected page — and a form submission posted from such a session is refused outright rather than redirected.
• Session cookies are HttpOnly, Secure, and SameSite=Lax, and the tokens behind them are rotated as they refresh.
• Sign-in attempts are kept in a short ledger: five failures against one identifier within fifteen minutes (or forty from one network address) close that door for the rest of the window, before the identity service is asked at all.

• Every account holds one role — a specific production step (spinning, dyeing, knitting, weaving, linking, cut-and-sew, finishing, pressing, packing, shipping), quality control, production manager, commercial, finance, brand, or executive — plus, optionally, an additive administrator flag.
• Access is granted by capability, not by role name. Every screen and every write asks for a named permission (for example orders.view, stage.knitting.update, invoices.manage); roles are granted those permissions as data, so what a role can do is auditable rather than scattered through code.
• The administrator flag is additive and narrow: it confers user management and access to the audit log. It does not confer sight of money. Prices, costs, margins and invoices sit behind a separate orders.view_financials capability that administration never implies.
• Row-level security policies in Postgres apply the same capability check inside the database, so a query that arrives without the capability returns nothing regardless of what the application layer did. The page and API layers check first, so a refusal is an explicit message rather than an empty screen.
• Deactivating an account withdraws every capability at once; it does not wait for an existing session to expire.
• Order status, provenance and sustainability links shared with a client are separate read-only pages reached by an unguessable per-order token, and carry no prices, no internal notes and no staff names. A token can be revoked from the order.
• All writes are attributed in the audit log, and the production ledger accepts no edits and no deletions — a correction is a new entry, not a rewritten one.

• All traffic is served over TLS 1.2+ with HSTS. We do not accept unencrypted HTTP.
• Database storage is encrypted at rest with AES-256 by our infrastructure provider.
• File uploads (invoices, packing lists, certificates, message attachments) are held in private object storage. They are never publicly addressable — downloads are always served via short-lived signed URLs generated after an authorisation check.
• Every page is served under a Content-Security-Policy carrying a fresh per-request nonce: a script the portal did not itself emit for that request does not run, and the portal may not be framed by another site.

• Every change to an order or a production stage is logged to an audit table, including the acting user, action, before/after values, and timestamp.
• Application errors are reported automatically to an error-tracking service.

If you believe you have found a vulnerability in the portal, please email b2b@blueskycashmere.trade with a description of the issue and steps to reproduce. We will acknowledge within two business days and do not pursue legal action against researchers acting in good faith.

The Portal is operated by Blue Sky Cashmere LLC, a Mongolian limited liability company (Reg. No. 5209811; State Reg. No. 9019032116). Registered office: SOR Building, 2nd Khoroo, Khan-Uul District, Ulaanbaatar, Mongolia. Phone: +976 9910 9463. Security questions: b2b@blueskycashmere.trade.