An admittedly wandering defense of the SSO tax
ssoready.com
ssoready.com
But this will usually show up in pricing structures with SSO as a relatively inexpensive add-on feature -- not as part of an indivisible bundle.
Seemingly we want to talk about both of these things as "the SSO tax" but I think we can agree that they're pretty different scenarios.
SSO issues usually takes 10 or 20 times longer to sort out any issue.
SSO issues took exponentially longer than nearly every other support issue and accounted for well over 50% of our support efforts.
We didn’t really feel like there was much we could do about it either. Most of it came down to the fact that the user of our application was not the person also able to setup SSO. The result was a massive game of pass the hot potato until we would get fed up and request a call with our customers IT team.
There are basically three major issues that require a bit of seniority to support:
* it’s an auth controlling system so mistakes can mean significant data breaches.
* there’s shared responsibility between provider and customer for configuration. Further, there are a lot of possible configurations to consider.
* the concept behind SSO is largely simple, but the implementation can be very complex. It’s almost always specific to your auth system and controls.
At WorkOS we solved this by shipping the whole config workflow in the form of an admin portal. It checks things like SAML certificate, signatures/assertions, attribute mapping, etc. and a zillion other edge cases across dozens of identity systems.
It’s pretty much “Stripe Checkout" for setting up SAML. Live demo here (click “Configure”) https://explore.workos.com/app/settings
That's my conclusion as well. We're a small shop and I used to feel a bit incompetent every time we'd setup SSO with a big client and it wouldn't work as it should, until I noticed that it was due to inconsistencies, misconfiguration, on their side more than half of the time.
Now I've accepted it though and I don't mind doing that part of my job. I know they feel somewhat incompetent on the other side as well.
I have to say, once it's setup it just works without any other intervention required though, I have very few support requests related to already existing SSO setups.
PS: the single most common developer error is assuming the SAML configuration is static and has a single certificate somewhere. The modern approach is to get all configuration from a metadata XML file including the multiple overlapping certificates that are used to implement seamless rotation on a schedule. If you haven’t accounted for this, you’ve “made it work” just like a child making a flying machine by throwing a rock.
(Guess what I was troubleshooting just this morning in a vendor product juuuust this morning. I’m not bitter this is the fifteenth time I’ve seen this exact issue. I’m not!)
I die Not make this experience. The specs exist and are detailled. I'm Not convinced your Last sentence ist true.
Even within the same profile, I've seen some major incompatibilities. For example, some Microsoft products interpret XML signing ever so slightly differently to many other libraries, breaking the protocol. (From what I could tell, MS was interpreting the standard correctly, others weren't, they were just testing against each other.)
The biggest gripe I have about SAML is that it's one of "those" committee-designed standards that has an inner-platform effect of using it's own custom extensibility model on top of the eXtensible Markup Language (XML). It's like the bad database schemas that have one table with three or four columns holding all data because the developers couldn't be bothered to learn SQL.
So instead of just this:
<claims>
<name>John Smith</name>
<email>john.smith@test.com</email>
<claims>
<saml:AttributeStatement>
<saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname- format:basic">
<saml:AttributeValue xsi:type="xs:string">test</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="mail" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">test@example.com</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
<saml:AttributeValue xsi:type="xs:string">users</saml:AttributeValue>
<saml:AttributeValue xsi:type="xs:string">examplerole1</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
The problem with the SSO tax is that it wedges itself into the pre-existing cracks in most organizations. Security practitioners are already in conflict with other departments. What happens when a department head has pitched a new SaaS as being 1x price, but then it becomes 2x price after the security team's requirements are added? It is not seen as the [application is expensive], it seen as [security team's requirements have doubled the price]. Conversely a price discrimination strategy which locks specific user facing features behind a specific tiers means that the same person championing the software, would also advocate for the appropriate payment tier.
Price discrimination is a valid strategy. Responding to organizations who are actively making the security practitioners job more difficult is also valid.
Of course this mostly means that if your required feature set falls into the "Contact us for pricing" tier then you're going to have to talk to a sales rep (probably several, from different vendors so you have a competitive quote) instead of getting any kind transparent pricing.
This was long lamented in the security-focused parts of the internet but no significant movement happened until late 2010 when the Firesheep extension made sniffing unencrypted passwords or session keys accessible to the masses. Suddenly it wasn't just security nerds complaining about things that could easily be brushed off by higher-ups, it was a problem that anyone who could install a Firefox extension (which thanks to ad blocking and the general badness of could see with their own eyes
Almost overnight major services decided that they in fact were fully capable of offering encrypted services to everyone. Suddenly client and server applications, SSL/TLS libraries, etc. that had been ignoring SNI all started supporting it over the next year or two so you didn't need a dedicated IP per hostname anymore. The ISRG was formed and developed Let's Encrypt to solve the problem of having to pay for certs, and while they were at it took the opportunity to develop and enforce the use of ACME with short-lived certificates so automation was effectively mandatory.
In six years we went from there being a "SSL/TLS Tax", which every part of the process would defend as absolutely necessary costs, to it being freely available to all and automatically supported by a lot of major application and service platforms.
I look at the SSO Tax situation as being mostly comparable from the user side of things. The internet as a whole would benefit from wide support for SSO, but the demand to solve the problem is minimal because most of the people making the purchasing decisions don't care about the problem enough to make it a requirement.
There are definitely some valid points that have been made about support costs associated with SSO, especially with regards to supporting more than just a couple of big name identity providers, but I don't think most people would complain if a vendor limited their free/cheap tiers to those couple of big systems those clients are likely already using. If someone needs custom integration they get to pay enterprise prices, but if they just want to sign in with Google that should be accessible to all. The support costs should scale well with a good implementation, hypothetically if Google or Microsoft changes something that breaks your integration you only have to fix it once to solve issues for everyone using it, as opposed to private identity services where each tenant might need something slightly different.
By all means charge enterprises more, but base it on something else, headcount, revenue, non-profit status...whatever.
Every time I hear about a data breach I wonder if someone avoided perfectly reasonable SSO protections because of this tax.
What "system" is bad and why? The poster made several arguments - which one of them are you rebutting?
The core idea that "you should have to pay more money for more features" makes sense from a basic economics standpoint (regardless of other rationalizations).
> I wonder if someone avoided perfectly reasonable SSO protections because of this tax
I don't know how much sense this speculation makes. SSO is complex to set up - without data, you could just as easily argue that misconfigured SSO makes breaches more likely, instead of less.
Plus, from a more practical standpoint, if you're frustrated about the never-ending stream of breaches (as I am), then it'd be better to push for laws that make the end result (personal data leaked) directly illegal with steep fines. There's too many different "upstream" problems (lack of SSO, default database credentials, buffer overflow in web application, misconfigured authorization system in webapp, etc.) for the strategy of "wage war against them one at a time" to be productive.
Why isn't SAML SSO mandated (either literally or my convention)?
Practically speaking, as someone who spends all day trying to convince developers to implement SAML SSO, I really wish this were the case :)
I think in practice, software vendors correctly assess that relatively few of their prospective customers actually care.
If many small / price sensitive companies really wanted SAML SSO from their vendors -- if there were really meaningful demand -- I imagine we'd see more pricing plans with SAML SSO bundled into entry level tiers.
As for mandates, this is a challenging ethical question. I don't think it's necessarily obvious in all cases that some institution should impose safety regulations upon us.
There's clearly some set of risks we accept, and some set of risks we don't accept. And we all draw the line in different places.
This is pretty obviously true. Not many of us worry about objects randomly falling off buildings. We don't all wear helmets all the time. It's certainly a risk, but do we really care?
I think the revealed preference from many software buyers is basically ... no, they don't care about having the security benefits of SSO.
I favor regulation on this, even though it's probably not necessary in every case, simply because I don't see any other way to break this equilibrium.
To be quite frank: this strongly suggests that while you put a lot of effort into writing a long article in defense of the SSO tax, you didn't perform more than the most cursory research about why it's a topic of discussion.
This argument is literally above the fold on the two top search results for the term.
>In short: SSO is a core security requirement for any company with more than five employees.
And the other explicitly makes the car-safety analogy:
>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power. Not offering security features if they already exist in your product means a vendor doesn’t care about your security. Our aim is to spotlight vendors who overcharge for security features, in hopes of instigating a change in the industry.
And to be franker: the word "security" appears exactly once in your entire piece. That's a near-complete avoidance of the actual issue that people are highlighting.
I perfectly understand the rationale behind the pricing model. The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer. That is and should be unacceptable.
I specifically meant that the previous commenter made me think of mandates.
I run a company that makes SAML SSO software. I've thought quite extensively about SAML SSO. See:
https://news.ycombinator.com/item?id=41036982
Addendum: I have a very strongly vested interest in more people using SSO. I literally spend my time trying to convince developers to set it up!
This is from a random website with no credentials that makes no arguments to back up its claim. It's meaningless.
>>Imagine buying a car and the manufacturer asks for an extra payment to unlock 100% of the braking power.
And this is a fatally flawed analogy that renders it useless. The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Neither of these quotes support this position.
> The point is that "only large enterprises need or care about SSO" is completely wrong-headed and detrimental to the overall security posture of any business customer.
As to this - is there any actual empirical evidence that missing SSO meaningfully weakens security for small businesses, which are the ones that would actually care about forking over the extra for the enterprise tier? That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage. I find it unlikely that missing SSO matters that much from them, and I'd like to see empirical evidence otherwise.
Also, there's nothing wrong for charging different amounts for different levels of security, assuming that that cost translates into actual effort (which it does for SSO). Normal people pay small amounts of money for physical door locks that are woefully insecure - the proposition that lock manufacturers should make their industrial and home locks cost the same would be pretty ludicrous.
Appeal to authority. Meaningless.
All I was pointing out with those links is that literally Googling the term "SSO tax" and clicking the first link at least hints at some of the reasoning behind people making an issue of this. The fact that TFA doesn't address any of the actual concerns people have in any meaningful way makes it of incredibly limited usefulness in the overall discussion.
> The situations of "hardware shipped that can't be unlocked until user pays" and "paying additional to support a feature that takes a lot of effort to develop, and actively takes more effort from the vendor to support" aren't remotely comparable.
Then charge for the support. The issue is that the only way to purchase a core security feature is bundled in with other features that the user doesn't necessarily want or need, very often at several multiples of the price for the features they do want.
>That doesn't sound very believable to me - small businesses are both disproportionately smaller targets, and also have much less complex IT systems with fewer logins to manage.
This is working from the faulty assumption that potential customers only exist in a binary between the nebulous "enterprise" and "small business with barely any IT competency."
I live in the enterprise healthcare world. It's routine for us to consider software purchases at the departmental level to fill a specific need for a particular team. We have hard requirements for SSO. Some of it's driven by internal policy, some of it's driven by auditors increasingly demanding MFA everywhere.
I have personally killed deals over this exact issue on a more routine basis than I'd like. Department head thinks cost is going to be Y. Cost is actually 5-10Y because the only way to purchase SSO support is via an "enterprise" bundle with additional features they don't need and an inflated minimum seat-count buy. We'd happily pay some middle ground for SSO support, but the option to buy it doesn't exist.
The issue is not charging for things that have support costs; it's forcing a customer into drastically higher pricing tiers under the assumption that running SSO is a signal that a potential customer has a super sophisticated environment and bottomless pockets. That was the world of 15 years ago, sure, but it's not today.
The reality is we live in a world where there are increasingly strict security requirements in many industries and any business paying, e.g., $6/user/month for Microsoft 365 has SSO available as an option.
I made this comment the last time the SSO Tax question came up: We routinely deploy our platform to large customers for 6 or 7 figure contracts. The number of them who actually deployed SSO (without just asking if we comply with it) is less than 20%.
In the past? People with enough weight would absolutely blow right past implementing SSO if it was slowing them down or adding to their cost.
These days it's a hard requirement for us: if it's not SSO it doesn't go into the environment. That's becoming the norm across the industry.
This is one of those very, very rare cases where healthcare is probably ahead of the curve relative to a lot of other industries. Consequence of being highly targeted by attacks and insurers starting to get very particular about how the ship is run.
SAML isn't exactly the best choice here. It's very SOAP-y; that's like being in 2005 and mandating everyone use SOAP+RPC for interopability.
I used OIDC for my internal sites to integrate with our corporate SSO provider. Why would I need to use saml instead?
I wouldn't celebrate taking those cars away from people.
As far as the older cars without those features allowing them to age out has almost entirely worked.
For the past 5+ years, the part of configuration that takes the longest - by far - is always SSO. I cannot imagine the amount of added support calls, time, and frustration brought about by it, so I can completely understand why some companies gate it behind more expensive tiers.
Nearly all specialty or line of business software, for example. These markets commonly have two or three providers and rarely have hundreds. Literally the intended purpose of copyright in this context is to give the authors market power.
And then the example given is the sympathetic one. The premise here is that there are the same number of customers willing to pay $40 as $10, and so the rational choice for a company not engaged in price discrimination is to charge $40 to everyone and price discrimination allows them to provide a "discount" to half of the customers.
Now suppose that only 10% of the customers would be willing to pay $40. The single-price profit-maximizing strategy is then to charge $10, because 100% x $10 is more than 10% x $40, and no customer benefits because all price discrimination does is allow them to overcharge the remaining 10%.
More to the point, in an actually competitive market, price discrimination isn't possible. If the marginal cost of providing the service is $7 and anyone is charging $40 to anyone, someone else could take those customers by charging $39, and someone else could take their customers by charging $25, until the market price is a thin margin over the underlying cost of providing the service. Because even the customers willing to pay $40 would prefer to pay $8, and the company that has 0.25% market share at $40 would rather have 10% market share at $8.
The better argument in favor of the "SSO tax" is the one from the comments: That SSO actually increases the cost of providing the service by raising support costs.
(1) That I assume companies never have market power.
(2) That I suppose "market power" implies monopoly
(3) That my example was cherry-picked.
1. I did no such thing. I explicitly acknowledged market power several times.
2. Again, not correct. I explicitly mentioned oligopoly (assuming that 'imperfect competition' wouldn't land).
3. Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
Your own comment claims that "actually competitive" markets can't have price discrimination. Sure, we can suppose the law of one price applies to perfectly competitive markets, but there's no sense in which a perfectly competitive markets "actually" exist at all! The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
My appeal to the airline industry as an example was not an accident. There's a very well-established literature on the relationship between competition and discrimination in the airline business. It's *certainly* not a settled question that discrimination decreases as competition intensifies. I included a classic from Stavins below that finds precisely the opposite of your claim.
My argument here isn't perfect. I can think of many flaws, many reasonable objections. But I don't think you're using any of them here.
---- Referenced paper from Stavins: https://www.bostonfed.org/publications/research-department-w...
Your premise is that if market power exists then market power is the problem rather than price discrimination. The issue is that price discrimination isn't possible without market power. Its presence implies that the company both is capable of and is overcharging the people coerced into the higher price tier.
> That I suppose "market power" implies monopoly
This is not an argument you make explicitly, but it's something readers commonly assume and my point is to highlight that companies successfully engaged in price discrimination can and do have market power even if they don't have a full monopoly.
> Of course it was. I acknowledged as much! I quite literally said the example doesn't generalize. The example serves to illustrate a 'there exists' claim. I felt a concrete example would be easier to follow than some kind of generalized model.
And I'm providing the 'there exists' claim for the alternative, to demonstrate that price discrimination can be (and often is) detrimental to customers without providing any countervailing benefit to any of them.
> The obvious observation we can make is that such competitive dynamics imply that no one would make any profit!
Profit doesn't really work that way. For example, if a company takes investment and uses it to buy a building to operate out of, the money not paid as rent to a landlord is added to the investor's profit, but if the company takes less investment and instead pays rent, the same money is counted as operating costs. Likewise, if you develop software needed before you can start operating and you take investment to pay for it, the net returns are called profit, but if you take a bank loan to pay for it then the interest on the loan is counted as operating costs again. The interest rate you'd pay the bank would even be proportional to the risk you'd fail, unless you post collateral, for which you'd need an investor.
So a company that didn't take any investment and operated entirely by renting everything, taking loans and using off-the-shelf software instead of developing anything in-house wouldn't be expected to make any profits in a perfectly competitive market -- and there would also be no investors to pay any profits to. Profit in companies that take investment would still be present and equal the cost (time value) of the assets bought with the money, but in a perfectly competitive market this would exactly equal the risk-adjusted market rate of return in the overall capital markets.
The distinction in uncompetitive markets is that profit exceeds that amount. (Or at least can; a market can be uncompetitive and then the companies become inefficient from lack of competitive pressure and waste the money they extract from customers instead of returning it to investors.)
It's true that "perfectly" competitive markets don't exist in the same sense that perfect anything doesn't exist, but this is splitting hairs. A gold coin might be .999 gold and you can say that it isn't perfect but you can still distinguish it from a wooden nickel.
"Overcharging" is a concept without a precise meaning. The SSO-capable version has a feature that cost money to build and support. That it is sold at a higher price (often alongside other enterprise features that cost money to build and support) is not proof that they are overcharging.
Any company that is tying to recoup the costs of building those features will charge the customers that use those features. The existence of a price differential between the 2 editions does not tell you whether they are overcharging.
"Price discrimination" is charging a higher price to one set of customers than another. The premise is that they're really getting the same thing but one of them has to pay more in exchange for either nothing or for something whose incremental underlying cost is far less than the incremental price increase, because the company devised a way to artificially segment the market.
If your argument is that the extra feature would actually cost that much even in a highly competitive market because it costs that much more to provide it, what you're really arguing is that they're not engaged in price discrimination.
Also, people wouldn't even mind if you added $2/user so you can't lose their creds and they don't have to remember your password. (For comparison, all of Microsoft E5 security tools together add ~$20 to M365.)
If you really want a differentiator they have to pay for that isn't SSO, go with "audit logs", "RBAC", and "Team Roles" management as lifts. Most anyone required to use SSO is required to use vendors that support audit logs. For SSO itself, you can also still charge for "automated group provisioning" (what used to be SCIM in SSO world). By the time they care about teams, they care about this.
See more features to charge for here: https://www.enterpriseready.io/
* This is on top of the argument from elsewhere in this thread, "Use our Google login then..." Note to the B2B startup bubble: more of your potential small, mid, and Fortune 500 business customers (where customer headcount > 1) can "Sign in with" Microsoft than Google. (Some estimates put it at 85%). Meanwhile, what startups and businesses on each side of B2B think they need legacy SSO/SAML for, most can actually meet all their requirements with this far more straightforward approach combined with a domain name control check and email domain filter.
The reason there's a belief of an SSO tax is not that you have to pay more to get SSO, it's that companies use SSO to get you to pay for features no-one ever wanted but they did a lot of development on because they know you need SSO.
And the gatekeeping of it behind sales people.
I’ve been around product development for 20+ years and I have NEVER seen a feature that “no-one ever wanted” get a lot of development resources.
What I see a lot are features that a few huge customers want get those resources, and other people without that perspective write them off as useless. Meanwhile we’re closing 9 figure deals on the backs of those “useless” features.
Airlines will mostly segment client based on things like Minimum Stay (in destination) and how many days before the flight the ticket was bought to find the most desired of all users: The business traveler.
SSO is (roughly) the same thing, companies who would like SSO are probably the ones in the corporate level, and this is an efficient way to find them. Of course there are false positives, but software companies are willing to live with those to get the biggest part of the pie.
And this is actually good for users, as it allows for the other users who have more flexibility to pay a lot less (both at airlines and software) than they would pay if those companies didn't discriminate.
Airports are natural, government-administered monopolies, who then typically auction off the rights for firms to sell to a captive audience with little to no competition. This typically results in unfair and wasteful allocation of resources.
My view is that you should use Cognito (simple) or Auth0 (simple but expensive) and build a self-setup page for it. Then if customers want it, it's on them to deal with configuring.
Oh, and push them all to OpenID because it's a lot less hassle than SAML.
If you're selling to big businesses (and you generally want to be), they'll pay for it anyway because this sort of security thing falls under various box ticking exercises for ISO certifications.
The society under whose umbrella we operate.
> a bottle of water should not cost $8” while waiting to board a flight at SFO. It’s very natural for us to say things like that.
The problem is the bottle of water is only worth $8 in part because they keep you from bringing in drinks not because its especially valuable at that time and place.
It's the difference between actually creating value and exploiting people out of their money
In fact, the exact opposite conclusion of the article is reached if we follow this logic. One of the taglines reads: Buyers want different things. Well, maybe the stakeholder/champion actually using your software might. But often they are not the ones that are making the money decision in an organization. The people who ARE making that decision, however, do not want different things. They probably could care less about different things. They want SSO.
I think it might be worth saying “SSO is free, up to n users”.
Also this is pricing for “adequate security”, which rubs a lot of people the wrong way.
But I do agree, competent, organizational wide SSO with SCIM is definitely an enterprise feature.
That being said, obviously this situation as described sucks and we should not move towards it because really all it does is push SaaS startups towards these two vendors to punt huge licensing fees down the road until they have the revenue to support it. And by then they are significantly locked in to these specific two vendors, two vendors that already have problematic approaches to monopolizing certain things. So fixing this is important but for a different reason than one might take at face value.
SSO is a hard requirement for us.
There have been many, many times where we've considered an application where we could justify the spend at, e.g., the departmental level for the limited user base that needed it, but where SSO being bundled into higher price tiers combined with minimum user counts took a potential solution from "very easy discretionary spend" to "not happening, full stop."
I'm often the one having to make these decisions. It's absolutely exhausting having to explain to non-technical department heads that "yes, this would solve your problem at a price that fits budget, but the vendor bundles a vital security feature into a tier that inflates the price to a point that it makes this unfeasible."
Either way, it's a surefire way for a potential vendor to automatically get lower priority from me as a potential buyer. Needing to haggle over what is, for us, a baseline security feature starts things off on the wrong foot.
But lately I've seen a flood of flat out complaining about things costing money.
As software devs we should be for software having a price tag, not against it
I think what annoys people is the reason why: a way to make more money from enterprises, and that they could make that money some other way.
If the landlord had to hire a bunch of extra support people, with expertise outside their normal domain, just to support swipe cards then this would make sense, no?
I can imagine a lot of products where accompany literally could not afford to provide support for SSO issues to a basic tier customer with 100 employees
The swipe system should be a very minor or zero part of the rent, not double.
This isn't a valid analogy to SSO. SSO doesn't just cost extra to develop (which in itself is a valid reason for charging more), but it costs extra to maintain - you can find several other comments in this thread alone talking about how difficult it is to support SSO from a technical/customer service perspective. People are expensive - both when writing code, and when supporting it.
If customers need additional human support for SSO then that can be charged separately.
In my experience most customers can get it working with no hassles or have hassle but their own tech resources figure it out. Few need to get support.
As a feature it is probably less work to implement and maintain than the simplest of product features.
YMMV if you have a complicated integration but if you just want to sign people in and assign them to a group for security it isn't hard.
Maybe we are talking cross purposes? I am talking about SSO with SAML and IdP rather than OAuth.
I suspect the reason for the SSO Tax is it is an predictor of "does this customer have money". Customers with more money to spend and absolutely need SSO to meet their policies will overlap alot.
Aren't the majority of enterprise contracts negotiated with support included? I thought that that was one of the main value adds for medium-to-larged sized companies.
And that’s assuming you don’t include auth in any of your release testing cycles (which you should). If you do, now you’re including unit and end to end testing with Okta, MS, Google, OneLogin, Jumpcloud, Ping, and anyone else your customers choose to use.
Don’t forget to run those tests with both SAML and OIDC. And make sure the engineers who know how to co figure each of those vendors’ SSO systems are aligned with your testing schedules.
Also don’t forget that you need dev/partner accounts with all of those vendors. And they’ll need to be active when you test.