How Your Cafe's Data Stays Safe from Other Businesses: Our Approach to Multi-Tenant Security

What Multi-Tenant Means and Why We Use It

Multi-tenant means many businesses (tenants) run on the same infrastructure — same servers, same database, same codebase. This is the standard model for modern SaaS, and for good reason: it's more efficient, cheaper to maintain, and updates can be deployed to all users at once.

But this model raises a valid question: if all businesses are on the same infrastructure, how is one business's data protected from another's?

Layer One: Automatic Query Scoping

Every database query in CrescendPOS is automatically scoped to the active tenant. This isn't something developers need to remember every time they write code — it's built into the framework. Every query that runs is automatically filtered: "only show data belonging to this tenant."

This means that even if there's a bug in our code, a query will never return data from another tenant — because the tenant filter is applied at a level deeper than regular application code.

Layer Two: URL-Based Tenant Resolution

Every business has a unique URL: /tenants/your-business-name/*. The tenant is determined from this URL before any code runs. This means there's no way to "break into" another tenant — you can only access data matching the tenant in your URL.

Layer Three: Layered Authentication

There are four authentication layers, each protecting a different access level:

• Devise (email + password): For admin and dashboard access
• Cashier PIN: For POS access at the operational level
• 2FA (TOTP): Optional but can be enforced per tenant — for extra security
• API Bearer Token: For integrations — each token is tied to a single tenant

Each layer is designed for its specific usage context. Admins use strong passwords. Cashiers use fast PINs. APIs use tokens that can be revoked at any time.

Layer Four: Audit Trail

Every sensitive data change — menu updates, transaction voids, price changes — is recorded in an audit log. The log captures who made the change, when, and what changed. These audit logs are also tenant-scoped — business A's logs cannot be viewed by business B.

What We Don't Do

We can't see your cashier PINs. PINs are hashed with bcrypt. Even our developers can't read them from the database.

We don't access your business data without reason. Access to tenant data only happens for legitimate debugging — and even that is logged.

We don't share data between tenants. There's no "industry benchmarking" feature that uses other tenants' data. Your data belongs to you.

Why This Matters to You

As a business owner, your sales data is sensitive. Menu prices, sales volume, margins — this is information your competitors shouldn't have. In a multi-tenant system, the guarantee that this data is isolated isn't a nice-to-have — it's fundamental.

We built this security not as a marketable feature — but as a non-negotiable foundation. Because user trust is the basis of everything.