The Benefits and Burdens of PCI SSF: What to Expect with Certification

As secure software development takes center stage, PCI SSF (Software Security Framework) is becoming a critical benchmark for vendors handling payment data. But certification isn’t easy—it involves rigorous testing, detailed implementation guides, and ongoing maintenance. So who should pursue PCI SSF, and what should you expect from the process? In this panel session, Tevora experts Clayton Riness, Austin Theen, and Shane Mayfield break down the benefits and burdens of PCI SSF certification. From understanding eligibility requirements to avoiding common pitfalls like incomplete implementation guides or unencrypted data in memory, the team provides clarity on how to approach certification with confidence.

What You’ll Learn:

• The benefits of getting your payment application listed under PCI SSF
• Which organizations and software types are best suited for certification
• Key elements of SSF that go beyond traditional PCI requirements
• Common roadblocks, from scope definition to memory handling, and how to overcome them
• How ongoing maintenance and version updates work once you’re certified
• What’s changing with PCI SSF v2.0—and how to prepare for the future

Whether you’re building new applications, managing SaaS solutions, or navigating compliance across industries like retail, healthcare, or financial services, this session delivers practical insights into strengthening your software security strategy

Thank you for joining. This is the benefits and burdens of PCI SSF. What to expect with certification. We’re going to be getting into the nuts and bolts of things around PCI, SSF, but by way of introduction, my name is Clayton Reines. I’m Principal Consultant here at Tevora and oversee a lot of our technical delivery areas, including PCI, including all the SSF work that we do, a lot of our penetration testing, incident response. I’ve been at Tevora for a long time, but I’m very pleased to be joined by two panelists. We’ll keep this as a panel type session. Here we have Austin Thien, who’s our senior architect. Austin, could you give a brief intro please?

Yeah, good afternoon. My name is Austin Thien. I’m a senior architect here at Tevora. While I’ve been here, just under a year I’ve been doing SSF and PCI DSS for probably, SSF for three years, PCI DSS for at least 12, and before that, I did digital forensics and incident response.

Thank you, Austin. We have Shane Mayfield, who’s Senior Consultant here Tevora.

My name is Shane. To give you a brief little background about me, I’ve been a QSA for the about the past 15 years, been doing it ever since back before we had reports on templates and did PCI DSS for a couple of years and been doing SSF for the past three years.

I think we should start with a little bit of setting the table on what SSF is. This was a pretty niche topic. We had some debate on whether we actually wanted to have a webinar about it, but there’s been great interest. So really appreciate you all jumping on here, but there is a history here. PCI formerly had the PA DSS standard, there is now the SSF and SLC standard. Austin, could you lay it out for us? How do these all work together? And what’s the current state of things?

Tthe secure software framework consists of both the two standards you mentioned, the Secure Software standard and the secure software life cycle standard, the SSF, really sets out a framework to define the applications in the payment space and the security steps that software vendors need to take in order to maintain payment data security the entire life cycle of that application, as it’s being developed, how it’s being tested, how it gets deployed. The way out through its end of life and in how it gets upgraded. It’s a really fairly rigorous testing and certification process, and the secure software life cycle goes hand in hand with that, instead of testing the application. Information that that certifies the software vendor for doing certain self-assessments on payment software themselves. It tests their development practices and the software development life cycle practices that they use to make sure that they meet up the standards of the SSLC and that allows them to do a bit more self-assessment for listed applications with PCI.

You mentioned listed applications, what are some of the benefits? Obviously there’s a lift to, I want to adhere to the standard. I want to get certified. There are some barriers. There’s some work you got to do. Why would want people want to do that?

The main benefit from getting a payment application listed is it allows you to use that listing for your clients, to list it under their PCI, DSS assessments, and help reduce the scope. It helps assure that the software that they’re selecting meets stringent criteria for payment security. It may be required for or obligatory, depending on the clients that you’re working with. I know there are some municipalities that require compliance software in order to win contracts. You can’t use non-compliant software.

I think applicability is important too. Not everyone’s running a payment application, but anything that handles cards in any way that may be used by a third party would potentially be in scope for certification. Is that correct?

Yeah, any software that uses payment data, merchant gateways, financial issuance, pos software, ecommerce software, there’s a whole bunch of applications that that could be in scope for, for SSF. What are some organizations, or what sort of application stacks, what’s, you, in your opinion, really the ideal target for SSS certification of a platform or service or a product?

There’s a lot of vendors out there. If I just think of some common software vendors, point of sale vendors are good examples, payment gateways, some mobile applications that that they’re developing some ecommerce platforms out there. There’s quite a bit of middleware that that have been registered, if I just think of some of the other vertical spaces. You could have retail hospitality that you know they’re out there creating apps that could be processing credit card data. Financial healthcare is a another good one, with their EHR systems, and some financial services industry. Because we got a fraud protection transaction, switches those types of things.

Who would be eligible for listing? Or why would you want to get listed? How does that work in practice, if you’ve gone through all this whole process to get certified?

There’s a set criteria that that’s govern whether they can be listed or not. It’s commercially developed software. It’s not anything that’s in in house grown so that that’s part of the eligibility requirements. They must be able to process payment data is another one, and one of the most common questions, a lot of people ask is whether SaaS applications meet the standard, and are they eligible for it? And yes, they are, as long as they can meet the eligibility requirements for it

It’s obviously pretty stringent to go through here and get the certification. I know that differs from some of the PA DSS stuff that’s been done in the past. Austin, can you tell us, or step us through, what is actually involved, than the work that you do to get an application from where it starts to being certified?

First, it starts with scoping the application, making sure that we’re getting all of the information that we need in order to set up the testing and everything else, from start to finish, the software vendor is going to need to be able to create an implementation guide go through and make sure all the processes surrounding the development of the application meet the SSF standards, and once they’re ready for that, then the assessment would come. All of the testing methodologies are clearly labeled in the framework, so it’s a matter of going through. Iif they do the testing beforehand, they should know what’s going to what’s going to happen when a third party like us comes through and does the testing, and then going through and in documenting everything from start to finish, it can take as little as three maybe four months to as long as I’ve seen it take as long as 18 months from start to actual listing, because there may be some gaps that were found during testing that needed remediation and assistance to work through. It really depends on the software vendor and the application.

I know at the end here there is a certification step. The council actually does sign off on this, is that correct? That’s part of what could be potentially introducing those delays in some cases. You have to do all this work, and you’re going into the bits and bytes of this application. You’re looking at memory, you’re looking at processes that are running.

We’re doing full forensic capture of memory immediately after transactions have occurred. We’re doing full disk forensics to make sure that that nothing is left on disk that could be used to compromise cardholder data or even any of the sensitive critical assets that are listed. We’re looking for anything like usernames and passwords to the application or key material that could be used to decrypt any of the protected data. It’s a very thorough analysis of the application.

Knowing how deep things go here, I know you have some experience in how far the standard goes and how that may contrast with other standards. People may think, I’ve got a SOC 2, or I’ve got ISO 27001, why would I need to do this certification as well? But obviously it goes in quite a bit deeper than those. Can you give us a taste for how much deeper that actually goes? And do you feel that this standard really goes above and beyond what others may be upholding?

If we take a step back and we look at the PCI SSF framework, it’s specifically geared for organizations that develop or sell payment software, as where we looked at other security frameworks like PCI, SOC 2, ISO. They have completely different scopes, completely different applications to them. If I contrast PCI versus SSF, there are totally two separate animals, even in controls that are applicable there?

I think it’s good to know, as people embark on this, maybe they got a new application. What do you normally see from new apps that people commonly overlook? I always think of PCI assessments. There’s always those half a dozen things that people normally struggle with. Are there equivalent, controls that people struggle with on the SSF side that are sort of gotchas that people should be aware of as they go through this process for the first time.

A couple of the ones that come to mind that I can think of are the implementation guide. That’s a pretty big one. The other one I see quite frequently is understanding the scopes. Other app, making sure that they list other critical assets that they know, all their critical inventories, those types of things. Those are some of the pretty big ones. You can’t get started in anything without having the implementation guide.

What about from your experience? What do you see as normal hang ups as people go through this process with you?

I’ve seen applications that have previously passed PA, DSS and think that they’re going to go through an SSF assessment without any changes. Typically, I find that unencrypted cardholder data in memory will flag as a compliance gap, in that it can be difficult to track down for the software vendor, that typically will delay things is far until they can track down what’s causing that, where it is. Another one is use of immutable objects. That’s a kind of a gotcha. It depends on how you handle it. But what that basically means is, if you write pan to a memory that’s immutable. You go to clear it, it doesn’t go away. Or you go to update it, and it just doesn’t go away until either garbage collection comes in, clears it out. And that could be from minutes to hours to days, depending on the particular environment it’s in.

I think it’s good to talk about how the SLC component works in here. Suppose I write a new app, and it’s for food truck service, and I’m taking payments. I’m brand new. I’m coming into this process. I mean, how would that work for me? You mentioned, it could be up to 18 months, or six to 18 months for the original certification piece. How does the SDLC component work in, how would that life cycle look like over the first couple of years for that application?

Initial architecture, laying out the application, assuming that software vendor has already gone through SSLC certification, they have rigorous and strict standards in place for the development process. They may also make key architectural decisions to avoid those pitfalls from before, without using immutable objects, without using things secure third-party libraries, making sure that everything is in line with that. Once they build out the initial proof of concept application, then they can start talking about doing their own internal testing against what the SSF assessor might do, and they can build their own unit tests to help with that process, once they get through an assessment. That’s a that’s a big step forward, and likely one that will help accelerate their certification process.

There’s a lot of prep work there. What would be the right resources? Shane, you can answer this as well on, how should people get up to speed on this before engaging, Tevora or another partner?

If you’re a software vendor, right, you want to make sure that you know some, some key steps that you look for. You want to make sure that when you’re getting this stuff, that you have a very mature risk management process. You want to make sure that your scope is well documented. That it’s really defined. That you know where all of your data is, those are some of the big ones that I can think of that are some common areas that that need to be really defined.

Going back to the food truck example, let’s assume I wrote a great app. I’ve done all the prep work. You guys are loving my implementation guide. You guys do the certification, and then I have to pay the council for that listing of that application. What happens after that? Do I have to come to you for every little update? How does the ongoing maintenance work once I’ve been certified once you list the application with the PCI and it gets listed as a payment application, you have three years of listing? That’s as long as the application will be valid annually, you’ll have to submit an attestation and validation that no changes have been made and you’re still upholding all of the requirements from the original assessment. If you make any changes to the app, like a new version comes out, or a version bumper, or something like that. Depending on the severity of the change, it could trigger a few different things. It could trigger an administrative change. That’s a very minor change, you change the name, you change some data information, but none of the actual application code changes, then you’ve got a small, minor change, which is more like some user flow, maybe some UI changes, but none of the critical functions, critical resources or critical assets change. Now this is where, if the software vendor is an SSLC, they may be able to do a delta change on their own. If they’re not a third-party assessor is required to perform those delta assessments. Once those Delta assessments are completed, we’re going to be looking at what’s changed from the application submitting that to PCI as, this is what’s changed. This is the new version. There’s an additional listing fee for going through the updated application the new version. They’re going to go through and look at the changes and validate that the assessor and the software vendor did everything that it’s supposed to, and then they’re going to go ahead and list it. And that would potentially solve their new version update, which is good.

Would you say that if someone is sort of rapidly wanting to release new versions of this software that they get the SLC, that would be almost be a requirement otherwise they got to run and get the whole thing certified over again.

It definitely would benefit a software vendor who makes rapid iterations to become SSLC certified. It can also be just for a smaller business unit that works on payment software that handles this stuff. It doesn’t necessarily have to be the entire development group. It could be a tiger team or a small business unit.

That does like the unit testing that would make sense. If someone’s approaching this for the first time, they got they have an app, they want to release it, they may be doing regular releases. Do you think they should be doing the SSS certification first and SLC later? Or are these happening at the same time? What’s the best order to do those in?

I would say it would probably be best to look at the SSLC first and then consult with an SSF assessor on the application to discuss scoping. It does there are some overlaps during an SSLC assessment that could be beneficial to an SSF, the actual application assessment. There might be some overlaps there.

Let’s talk about what happens when certification actually lapse. I know you have to get recertified. There’s a little bit of a grace period, but ultimately there is some pain if you do lapse, right? What does that life cycle look like? You think you have one year and you have to research, is that correct?

If for one reason or another, the software vendor doesn’t attest that they’re meeting all the SSF requirements of their prior assessment, the listing will go from green to yellow to red stoplight protocol. Essentially, once it gets delisted, if they fail to renew the software and all the associated fees with that, then it would be like the application was, it needs to be relisted again. It’s another full, complete assessment, like the application was never listed.

Of course, the whole idea here is, you have a listed application. You’re using that if, let’s say you’re a consumer of this application. You’re using this certification as a way of limiting your exposure to PCI when you go through your own assessment. That’s the magic, right? That’s why people want this. In thinking of that, let’s say, if it does lapse, how do we handle that from a compliance standpoint? There’s always the third party service providers and your AOC lapses. Is that a non starter? Is there something equivalent here that’s happening on the SSF side, when it comes to non-compliance or lapsed compliance, as far as merchants using it?

It’s typically going to be the merchants that are going to press the software vendors for that to be renewed, to follow up on that. It could also be the merchant banks looking for registries to be updated, like the visa service provider registry similar to that. There’s definitely a lot of pressure to maintain that listing for all the knock on effects that happen when it gets delisted, it’s not fun. I don’t recommend that.

I know it’s certainly an evolving standard. There is something pending. I think PCI generally goes through a renewal cycle every few years for all of their standards. I know there’s since SSF is relatively new and STLC is relatively new, there is a new version coming out and some changes afoot. Is that correct?

Yeah, they just released a RFC for SSF version 2.0 about a month or two ago, and that request for comment got a lot of good stakeholder feedback. They’re taking a lot of the feedback from version 1.2 and taking that to heart to update the whole framework. One of the big, big things is you. The sensitive assets documentation is coming out into a separate document now, and they’re offering better definitions of what sensitive assets are, all of the key components within the application that data, whether it’s sensitive, whether it’s critical, whether it’s payment data or not, it could be payment data, authentication data, encryption, key material, all of that is getting a little bit more refined in the next version. I’m anxious to see what when it comes out, and what it what it entails in thinking of SSF two Dotto and even PA.

The PCI standard 4.0, we seem to be getting more controls and things becoming more stringent. Do you think broadly we’re going the right direction? This may be something for Shane and Austin. More is always better, but maybe not. Are we moving generally in a better state and in the right direction, becoming and trying to become more secure here, as we improve these standards?

If I think back on when I first did PA DSS, when I did those assessments, it was more of just a regurgitation of controls that were already in PCI DSS. Encrypt cardholder data, which we already there. When I transitioned over to SSF from PA DSS, it was kind of embarrassing.  Because they were adding more controls that are not necessarily in the PCI standard. Some good examples, is making sure the software is secure by default, adding tamper resistance inside of the applications. Now, another big one is update integrity, making sure that updates are security coming by. I remember one of the other biggest changes was the encryption key strength had to be 128 bits when Essa first came out. PCI was still using triple DES. Triple DES was still allowed. The other thing was, we were looking at, the random number generators and having to do Threat Modeling from a vulnerability management standpoint. I think the standard going in the in the right way. They’re adding more application centric controls that need to be there, to protect things.

I also think that they’re realizing that the development model is changing, the environment is changing. Everything is moving to the cloud. There’s more software as a service solutions out there, and I think they’re evolving the standard to help the certify applications that take full advantage of those features and capabilities.

When I remember when PA DSS came out, it was generally one type of landscape. The cloud wasn’t really big then, I mean, it was, it was around, but it wasn’t as big as it is nowadays. There wasn’t a ton of sad applications floating around, but now it’s just exploded in all these different technologies. Now we have AI up and coming, and colors are going to add in the AI controls to the SSF standard. It’s the landscape has definitely changed since those days.

There was a question that came in, how do you see PCI SF evolving over the next few years, which I think we covered but there also is a second question about trending and how companies should best prepare moving forward. Some of that we may have touched on but based on the two Dotto changes that are coming up, if they’re starting right now. What are some top things that people should be thinking about and worried about as we as they prepare for certification here?

The top thing is read the standards, understand the standards. Understand that, because when we first had PA DSS, there was only one standard, and now we have two. They kind of broke out the SDLC versus the security testing, which is the SS side. So, very familiar with those standards, understand all the technical controls. Sometimes technical controls may be there. Sometimes they may not be applicable to your software. The other thing if you’re just now starting out on the SSF journey, do a self-assessment. Go do a full internal gap analysis. Compare how your software is now against the SSF. Requirements and see where you stand, because that that will guide a lot of things. The other big one is pull down the standard. It’s not pay walled or anything.

When you pull it down and read it, there’s the standards are there, the program guides there. If you need to go look at, does your software meet the eligibility requirements, you can go look in the program guide and see what those are. They list a lot of good tables and flow charts. When we talk about the administrative change versus the low impact change versus the high impact change. There’s a lot of good supporting documentation in there that will basically tell you, if you’re SLC qualified, versus a non SLC vendor, what you can do. The council’s put a lot of thought and effort into creating these program guides and giving as much information as possible. I would say another thing for companies who are just starting the certification process is build a culture of security all the way from implementation from concepts all the way to implementation. Be thinking about those and keep all those things mindful as you start your journey through the SS process.

So don’t just vibe, code a bunch of stuff and fire it off. Be practical.

Exactly right. There’s a lot of things that are in the tenant control site that kind of need to be planned. Trying to think of a good one off top of my head. That thing really comes like a good one would be, how you implement patching. There’s a couple of things that need to happen. How do you inform your stakeholders? There needs to be well defined processes, even from the app side. You need to make sure the application is securely getting updates.

Updates always need a patch, especially for embedded devices. I feel like they’re always neglected. Those embedded systems that don’t get touched. I don’t believe we have any more questions here, Austin, any closing thoughts here as we wrap this up?

There’s a lot in SSF, and sometimes it can seem overwhelming, but we’re definitely here to help and we can get you through this.

If you do feel overwhelmed, we do, we can always help you with this process, even if you’re just if you’re just starting out, or if you have a mature application and you need help out shoot, we’ve been doing PCI for a long time here at Tevora. Obviously, Austin and Shane have a lot of experience in tearing down applications and helping people get certified, but hopefully you’ve learned a little bit about the standard during this session. I appreciate you all joining and thank you very much.