This article brings together common customer questions and practical answers based on typical Secureframe workflows, compliance situations and unique tech stacks.

It is meant as quick reference material for day-to-day use of the product.

Encryption and cryptography

Do I need to disable AWS volume encryption to enable BitLocker on EC2?

• No. Disabling AWS-native volume encryption is not required and is not recommended. In fact, Secureframe tests require EC2 instances to have encrypted volumes enabled under AWS.

  BitLocker cannot be used on EC2 instances, so there is no need to adjust AWS volume encryption settings for this test. Simply ensure that workstation endpoints are encrypted with the appropriate tool (BitLocker or FileVault).

Is an entity allowed to store the PIN block after the completion of the authorization process if they encrypt it again?

• Even if an entity encrypts the PIN block again, it is still not allowed to be stored after the completion of the authorization process.

Is AWS Simple Queue Service Encryption (SQS) a hard requirement?

• No, it’s not a hard requirement. It’s a good practice, but if you’re not using it for the audit, you can disable the control until SQS is implemented. If you have encryption at rest, you meet the requirement.

Until what date is encrypting stored SAD with strong cryptography considered a best practice?

• The bullet above (for encrypting stored SAD with strong cryptography) is a best practice until 31 March 2025, after which it will be required as part of Requirement 3.3.3 and must be fully considered during a PCI DSS assessment.

What does "cryptographic agility" refer to?

• “Cryptographic agility” refers to the ability to monitor and manage the encryption and related verification technologies deployed across an organization.

What if you don’t have a plan to use Hard Drive encryption?

• Document the lack of hard drive encryption in the risk register and implement compensating controls, such as prohibiting employees from downloading customer data, using MFA, locking screens, or maintaining up-to-date OS and anti-malware.

What should be documented and reviewed regarding cryptographic cipher suites and protocols in use?

• Cryptographic cipher suites and protocols in use should be documented and reviewed at least once every 12 months, including an up-to-date inventory of all cryptographic cipher suites and protocols in use, active monitoring of industry trends regarding continued viability of all cryptographic cipher suites and protocols in use, and documentation of a plan to respond to anticipated changes in cryptographic vulnerabilities.

What should be examined to verify that all SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography?

• Examine data stores, system configurations, and/or vendor documentation to verify that all SAD that is stored electronically prior to completion of authorization is encrypted using strong cryptography.

What should be examined to verify that authentication factors are rendered unreadable with strong cryptography during transmission and storage?

• Vendor documentation and system configuration settings.

What steps should be followed to encrypt an Elastic Block Store without creating a new instance and volume?

• To better understand the issue, could you confirm how the new instance is getting created?

  If it’s due to an Auto Scaling Group, Launch Template, or any automation, it may be enforcing instance recreation when encryption is enabled.

  Also, please note AWS has a limitation where existing EBS volumes cannot be encrypted in place. Instead, AWS requires creating a new encrypted volume and attaching it to the instance. If encryption is enabled at the instance launch level, any automation scheduling new instances will ensure encryption is always applied.

Where can more details on the choice of protocols, configurations, and settings related to cryptography be found?

• Review the vendor’s specific documentation for more details on the choice of protocols, configurations, and settings related to cryptography.

Why do the Secureframe SQL Server Transparent Data Encryption (Azure) test instructions not match the options in the current Azure portal?

• Azure frequently updates its portal and settings layout, which can make the Secureframe test instructions appear slightly different from what you see in the Azure UI. In most cases, the encryption settings are still valid but may be labeled differently.

  For SQL Server Transparent Data Encryption (TDE), Azure now emphasizes the use of a Customer Managed Key (CMK) rather than only the server-level encryption key. If your settings show TDE enabled with the appropriate key configured, your database is encrypted at rest even if the instructions look outdated.

  If Secureframe is still flagging the test as failed:

  Confirm that TDE is enabled in Azure.

  Check whether a CMK or service-managed key is being used.

  Resync your Azure integration in Secureframe to pull in the latest status.

  If the test continues to fail even though the settings are correct, please reach out to Secureframe Support and share a screenshot of your configuration so our technical team can confirm or adjust the test logic.

Encryption at rest and keys

Does encrypting SAD with a different cryptographic key than is used to encrypt PAN mean that PAN present in SAD (as part of track data) would need to be separately encrypted?

• Note that this does not mean that PAN present in SAD (as part of track data) would need to be separately encrypted.

How do I check for wildcards in my KMS key policies?

• Go to AWS Console > Key Management Service > Customer managed keys.

  Select a key, scroll down, and click Switch to policy view.

  Look at the "Principal" field. If it contains "*" or an overly broad "AWS": "*" without conditions, that’s a wildcard and should be removed.

Is AWS KMS required? Or can we use our own AWS keys?

• AWS KMS is not necessarily required. Encryption over databases, network traffic, and environments is required. AWS KMS is a good option, but custom AWS keys can be used if not using AWS-managed keys.

Is data encrypted at rest?

• Sensitive data is encrypted at rest in RDS, Redis, Elasticsearch, and S3 using AWS KMS-managed keys. Data is transmitted using TLS encryption from S3 via Cloudflare, and key rotation occurs quarterly.

Is it safe to use wildcards in KMS key policies?

• Generally, no — wildcards increase the risk of unauthorized access. Use them only when absolutely necessary and always pair them with IAM Condition statements to limit scope (e.g., by IP, VPC, or tag).

What is the purpose of changing wireless encryption keys?

• Changing wireless encryption keys whenever someone with knowledge of the key leaves the organization or moves to a role that no longer requires knowledge of the key, helps keep knowledge of keys limited to only those with a business need to know. Also, changing wireless encryption keys whenever a key is suspected or known to be comprised makes a wireless network more resistant to compromise.

What should be examined to verify that access is managed for each system component via an access control system(s) that restricts access based on a user’s need to know and covers all system components?

• Vendor documentation and system settings.

Where can I find further information on cryptographic algorithms and key lengths?

• Refer to NIST SP 800-131a, Transitioning the Use of Cryptographic Algorithms and Key Lengths.

Where can the definition of "keyed cryptographic hash" and for information about appropriate keyed cryptographic hashing algorithms and additional resources be found?

• Refer to Appendix G for the definition of “keyed cryptographic hash” and for information about appropriate keyed cryptographic hashing algorithms and additional resources.

TLS and data in transit

Encryption in transit for web applications?

• Ensure SSL or TLS is in place for client web portals. Take a screenshot of the certificate as proof.

How does your application protect data in transit and at rest?

• All customer data is stored within our AWS environment, segmented by customer ID and encrypted using AWS’s native encryption services.

In the DFS control, "End-user messaging technology encryption-in-transit." Is that referring to external or internal messaging?

• End-user messaging technology encryption-in-transit is External messaging as it is referring to end users.

  If you are thoroughly encrypted and passing other tests in that control family this particular control may not be a hard requirement.

What appendix applies to entities using SSL/early TLS for card-present POS POI terminal connections?

• ppendix A2: Additional PCI DSS Requirements for Entities Using SSL/Early TLS for Card-Present POS POI Terminal Connections.

What is the rule regarding introducing SSL and early TLS into new environments?

• SSL and early TLS must not be introduced into environments where those protocols don’t already exist.

What method is used to encrypt data in transit?

• TLS or SSL certificates are used to encrypt data in transit. A screenshot of the SSL certificate can be used as evidence.

What must all service providers with existing connection points to POS POI terminals that use SSL and/or early TLS have in place?

• ll service providers with existing connection points to POS POI terminals that use SSL and/or early TLS as defined in A2.1 have a formal Risk Mitigation and Migration Plan in place.

What provisions are included to support entities working to migrate from SSL/early TLS on POS POI terminals?

• New POS POI terminal implementations must not use SSL or early TLS as a security control, all POS POI terminal service providers must provide a secure service offering, service providers supporting existing POS POI terminal implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place, and POS POI terminals in card-present environments that can be verified as not being susceptible to any known exploits for SSL and early TLS, and the SSL/TLS termination points to which they connect, may continue using SSL/early TLS as a security control.

What should be done if SSL/early TLS is not needed in the environment?

• If SSL/early TLS is not needed in the environment, use of, and fallback to these versions should be disabled.

What should entities do where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS?

• Where POS POI terminals at the merchant or payment acceptance location use SSL and/or early TLS, the entity confirms the devices are not susceptible to any known exploits for those protocols.

What should entities using SSL and early TLS for POS POI terminal connections do?

• Entities using SSL and early TLS for POS POI terminal connections must work toward upgrading to a strong cryptographic protocol as soon as possible.

Where can I find further guidance on SSL/Early TLS?

• Refer to the current PCI SSC Information Supplements on SSL/Early TLS for further guidance.

Who is the requirement intended to apply to regarding POS POI terminals using SSL and/or early TLS?

• This requirement is intended to apply to the entity with the POS POI terminal, such as a merchant.

Additional customer questions

What is the purpose of encrypting all non-console administrative access?

• If non-console (including remote) administration does not use encrypted communications, administrative authorization factors (such as IDs and passwords) can be revealed to an eavesdropper. A malicious individual could use this information to access the network, become administrator, and steal data.

Do I need centralized key storage for SSH keys?

• No, not in the same way.

  SSH key management is related but different:

  You don’t store SSH private keys in a key management system like AWS KMS

  Instead, focus on:
  Restricting access to private keys
  Rotating keys periodically
  Disabling unused or expired keys
  Auditing who has access to which systems
  SSH key use is typically governed by access control policies, not cryptographic key storage policies.

What is centralized cryptographic key storage, and how do I implement it in Heroku?

• Centralized cryptographic key storage refers to using a dedicated, secure system to generate, store, rotate, and manage cryptographic keys (e.g., for encryption, TLS, or API credentials). Examples of centralized key management solutions include:
  AWS Key Management Service (KMS)
  HashiCorp Vault
  Azure Key Vault
  Google Cloud KMS
  In a Heroku context, you typically implement this by:
  Storing secrets and keys in Heroku Config Vars (note: not ideal for highly sensitive data)
  Or, better yet, integrating your app with an external KMS (like AWS KMS or Vault) via API calls
  If you're not storing any sensitive data (like PII or customer credentials), you may not need centralized key storage. But if you’re encrypting data or using TLS certs, you should ensure keys are stored securely, rotated regularly, and not hardcoded in your codebase.