Affirmed Identity LLC is at once both a 'Technology Supplier' and a 'Service Provider'. In other words, its core offering, 'authentication as a service' (AaaS), is offered both as a service and as a product at the same time. The reason for doing so is the accepting the rationalization of needs and abilities.

As a service provider, we provide organizations with the option to address their user authentication needs using our AffirmedID authentication services. As a technology provider, we offer the option to license the AffirmedID kit for in-house installation and use. And indeed, that in-house use may be in direct competition with our own AaaS service offering and that's okay with us. It's easier to understand this seemingly conflict of interest after reading results of our analysis and findings detailed here.

The need to meet and comply with both Payment Card Industry Data Security Standard (PCI DSS) and Zero Trust Architecture (ZTA) and to do so within the strict guidelines of GDPR et al. are faced by many organizations worldwide. Indeed, most organizations fall into one camp or the other, and in some cases, both.

PCI DSS is a set of security standards created by the Payment Card Industry Security Standards Council (PCI SSC). Compliance with PCI DSS is mandatory for all organizations that handle credit card information, and proof of compliance is required.

ZTA has a broad and growing range of support and is best defined by NIST documents beginning with SP 800-207. While use and compliance is optional, every agency of government and many organizations have begun adoptions of ZTA. While there isn't a specific timeline for ZTA accreditation, the growing adoption of ZTA principles suggests formal accreditation may emerge in the near future.

And of course, the very nature of authenticating one’s identity suggests a need for information and data regulated by agencies and standards such as GDPR, HIPAA, and others. In some cases, these regulations may also include accreditation requirements for some.

While ZTA and PCI DSS are very different standards targeting very different needs, there are shared commonalities relating directly to user identity and the task of verifying and monitoring. These include:

• Focus on Data Security: Both emphasize the importance of protecting sensitive data. PCI DSS 4.0.1 specifically targets payment card data, while NIST SP 800-207 provides a broader framework for securing all types of data.
• Multi-Factor Authentication (MFA): Both advocate for the use of MFA to enhance security. PCI DSS 4.0.1 mandates MFA for access to cardholder data environments, and NIST SP 800-207 recommends MFA as part of a Zero Trust Architecture.
• Risk Management: Both emphasize the need for comprehensive risk management practices. PCI DSS 4.0.1 includes requirements for information security policies, while NIST SP 800-207 provides guidance on managing cybersecurity risks.
• Continuous Monitoring: Both highlight the importance of continuous monitoring and regular assessments to ensure ongoing security. PCI DSS 4.0.1 requires regular security testing and vulnerability assessments, while NIST SP 800-207 promotes continuous monitoring as part of the Zero Trust model.

A significant commonality not expressly stated is the need to “never trust, always verify”. For ZTA it is a core principle. For PCI DSS, the concept is embedded in its security requirements.

As indicated, PCI DSS and ZTA agree on many areas. There are some differences as well, most of which stem from intent differences. PCI DSS is a standard with mandates making compliance obligatory for organizations handling payment card data within the cardholder data environment (CDE). ZTA is a Special Publication with strong emphasis on critical needs and whose adoption is highly recommended but compliance is not mandatory yet.

In summary, There are some notable similarities between these otherwise unrelated standards. These similarities relate directly to the need for secure, accurate, and trustworthy user authentication and monitoring of the ensuing authenticated session.

The two options for achieving organization authentication service needs are:

• To delegate authentication to a third party, and transfer responsibility at the same time. The options include 'Identity and Access Management' (IAM), 'Identity Provider Services' (IdP), 'Authentication Services' (AaaS), and 'Password Managers' (PM).
• By bringing authentication services in house, the organization assumes responsibility for them. Large enterprises and many in finance and healthcare do so. Smaller businesses often see this as a challenge beyond their reach. As we’ll see, this may not necessarily be the case.

That said, the reader should note that Affirmed Identity LLC offers both options. However, it limits access to the service provider option to smaller organizations who cannot adopt their own in-house solution.

There are several factors to consider when making this crucial decision. The following are some of the more critical needs or those that are more difficult to implement.

First of all, is there a choice? In some cases, in-house may be the only option because of industry or regulatory requirements.

The need for continuous monitoring may be a requirement of PCI DSS and a recommendation of ZTA. Government agencies may impose contractual obligations to do so. Of course, common sense suggests it’s a good security measure for every business.

MFA is required by PCI DSS, strongly recommended by ZTA, likely required by government agencies, and of course, common sense as well. Take note of the requirement for distinct factors as this rules out most so-called MFA solutions such as Push, most OTP solutions, FIDO2, and Passkey.

Delegating authentication to a third party may appear to be the most immediate, affordable, and attractive solution. However, in almost every case it conflicts with ‘never trust, always verify’.