A pattern in enterprise software has bothered us for years. A vendor charges a small team a modest per-seat price for the product, then charges that same team several times more per seat to add single sign-on. The same SSO that, on the vendor's side, costs almost nothing per seat once the integration exists. That price is not cost recovery. It is a gate on the controls a buyer needs to deploy the product safely, sold back to them as a premium.
When we decided what belonged in each tier of Atlas, this was the question we argued about the longest, and we want to be exact about where it landed. Every plan, including Free, gets encryption in transit and at rest, two-factor sign-in, and role-based access. Google and GitHub sign-in, custom roles, and the audit log are on paid plans, and SAML single sign-on, SCIM provisioning, and data loss prevention are on the higher paid plans. None of them requires a separate enterprise-only contract. This post is the long version of why the lines sit there, and an honest account of what the argument asks of a vendor, including us.
The controls that should never be paywalled
Four controls decide whether a product is safe to deploy inside a competent organization. They are not the only controls that matter, but they are the four where a paywall does the most damage.
- Single sign-on. If a product cannot authenticate against the company's identity provider, every account is a separate password to rotate, every departure is a manual checklist, and every joiner is a help-desk ticket. SSO is how access follows employment instead of drifting away from it.
- Role-based access. A product where everyone is an admin is a product waiting for an incident. Named roles that map to what people actually do keep write access scoped and offboarding clean.
- An audit log. A product that records who did what, when, can be reviewed after something goes wrong. A product that does not, cannot. The cost of adding audit logging after the fact is large. The cost of writing it in from the start is small.
- Encryption in transit and at rest. Every managed platform gives you TLS for free and volume encryption on the storage layer by default. A vendor that meters either as a paid add-on is charging for a checkbox it did not have to build.
If any one of these sits behind an upgrade, the lower tier is not the tier to roll out across an organization, and the vendor should say so plainly on the pricing page rather than let a buyer discover it after a rollout. What a vendor should not do is hold them back for a contract only the largest buyers can sign.
What it costs the vendor to give these away
None of this is free to build. Single sign-on is a real integration and a real surface to keep working as identity providers change their behavior. Role-based access has to be designed into the data layer early or retrofitted painfully later. An audit log is cheap if you write it from the first commit and expensive if you bolt it on after a year of features have assumed it is not there. So the controls cost engineering time, and we are not going to pretend otherwise.
What they do not cost is per-seat money. Once SSO works, the ten-thousandth login costs the vendor nothing the tenth did not. That is the tell. When a control has a high one-time build cost and a near-zero marginal cost, and a vendor still meters it by the seat, the price is not paying for the control. It is paying for the buyer's lack of alternatives.
Putting these in the base tier costs the vendor the thing the Enterprise SKU was quietly collecting: the tax on regulated buyers who cannot say no to SSO. Giving that up is the real cost of secure by default, and it is a revenue cost, not an engineering one. Atlas pays part of that cost, not all of it: the baseline controls are on every plan, and SAML SSO, SCIM, custom roles, and the audit log sit on paid plans that any team can choose from the pricing page, without a sales call.
Where SOC 2 fits, and where wrxstack sits
There is a second thing buyers ask for, and it is easy to confuse with this argument, so we want to separate them. Procurement teams ask for a SOC 2 report and treat it as the security gate. A SOC 2 report tells a buyer that a vendor wrote down its controls and an auditor checked they were followed for a stretch of time. That is worth something. It is also a different axis from the one this post is about. SOC 2 measures whether you do what you say. It does not measure whether the basic controls reach every customer or only the ones on the Enterprise plan. A vendor can hold a clean SOC 2 and still paywall SSO, and plenty do.
We should be plain about where wrxstack sits, because the argument only works if we are. wrxstack holds no certifications. No SOC 2, no ISO 27001, no third-party audit, no penetration test. If you are evaluating it for regulated data, the honest answer is to choose a vendor that has those things. What we are claiming is narrower: the baseline controls are on every plan, and the identity and accountability controls are on paid plans rather than reserved for an enterprise-only contract. The security page says the same thing, including every part where the answer is no.
The audit log is the control people underestimate
The audit log is the control we argued hardest about, because it is the one that changes what a customer can do after something goes wrong. It records who did what and when: the account, the action, the target, the time. In Atlas it also records what the assistant did, because a product where an AI agent takes actions on a user's behalf needs the agent's actions in the same log as the human's, with the same fields. Without that, half of what happened in the account is invisible, and the half you cannot see is exactly the half you will want to reconstruct later.
Here is the honest scope. It is an activity log you can read inside the app. It is not streamed to an outside system, it is not cryptographically signed, and it is not held for years on our infrastructure. We are not going to describe it as more than it is. It is on paid plans, and the pricing page says which ones before you sign up.
What "secure by default" does not mean
It does not mean shipping every control anyone could want. Atlas does not have customer-managed keys. It does not have data-residency selection or a single-tenant deployment, and it has no uptime SLA. Some of those are deliberate choices and some are simply not built yet. The security page lists all of them under the heading of what wrxstack does not do. Baseline is not the same as complete, and we would rather be clear about the difference than blur it.
It also does not mean security is free for the customer. You still have to configure SSO, scope what the assistant is allowed to touch, and actually read the audit log when it matters. We tried to make those steps small. They are not zero.
The two things other vendors get wrong
Enterprise security as a SKU. The "Enterprise" tier exists mostly to gate the security features. Pricing shifts from per-seat to per-conversation or per-quote, and there is no meaningful product difference between the tiers other than the controls. This pattern lets a vendor collect a tax from regulated buyers in exchange for not shipping the controls to everyone. It reads as a pricing decision and lands as a safety decision.
Security as a checkbox. The vendor claims SSO, but the implementation only supports one identity provider. The audit log writes to a place the customer cannot read. The role model has exactly two levels, admin and everyone else. This pattern lets a vendor claim parity on the comparison grid without doing the work behind the claim. It survives a feature matrix and fails the first real deployment.
Both patterns are visible in a careful procurement review, and both fail the only test we actually trust: would we deploy this if our own jobs depended on it. We picked the defaults to pass that test, and where a control sits on a paid plan, the pricing page says so before you commit.
The full and unflattering version of what wrxstack does and does not do is on the security page. If you want to argue about any of it, write to contact@wrxstack.com.
Where this lives in wrxstack: Atlas for enterprise and the Trust Center.