Preparing for the AWS Marketplace Security Review: A Complete Guide to Passing the AWS FTR

Listing your SaaS product on AWS Marketplace opens access to thousands of enterprise buyers who prefer procuring software through their existing AWS billing relationship. But before your product appears in the Marketplace, it must pass the AWS Foundational Technical Review (FTR), a security and architectural assessment that validates your product meets AWS's baseline standards for customer trust.

The FTR isn't a checkbox exercise. AWS reviews your product's security architecture, IAM implementation, data handling, logging, networking, and operational practices against specific technical requirements. Products that fail the FTR don't list. Products that pass with issues receive conditional approval with remediation timelines. Only products meeting all requirements receive clean approval.

For SaaS companies, the FTR intersects heavily with existing security and compliance work. If you're already SOC 2 certified, many FTR requirements are already met. If you've completed a SaaS security assessment, your architecture likely aligns with FTR expectations. But the FTR has AWS-specific requirements that general compliance doesn't cover.

This guide provides the complete preparation roadmap: what the AWS FTR evaluates, how to prepare your application, the common failures that delay listings, and the security testing that validates FTR readiness.

What Is the AWS Foundational Technical Review?

The AWS FTR is a technical assessment that AWS requires for products listing on AWS Marketplace. It evaluates whether your product follows AWS Well-Architected Framework best practices across security, reliability, performance, and operational excellence.

Why AWS Requires the FTR

AWS Marketplace customers trust that listed products meet a baseline quality standard. The FTR protects that trust. A product with exposed credentials, misconfigured IAM, or unencrypted customer data reflects poorly on AWS Marketplace as a platform. The FTR ensures every listed product meets minimum security and architectural standards.

Who Must Complete the FTR

All software products listing on AWS Marketplace: SaaS applications, AMI-based products, container products, and professional services with software components. Both new listings and major version updates require FTR review.

FTR Review Process

Step 1: Self-assessment. Complete the FTR self-assessment checklist evaluating your product against each requirement.

Step 2: Submission. Submit your product and self-assessment to the AWS Partner team.

Step 3: Review. AWS technical reviewers evaluate your product architecture, configuration, and documentation against FTR requirements.

Step 4: Feedback. AWS provides a report identifying any requirements not met, with remediation guidance.

Step 5: Remediation and re-review. Address any findings and resubmit for verification.

Step 6: Approval. Product approved for AWS Marketplace listing.

AWS FTR Security Requirements

IAM and Access Control

AWS FTR requires that your product follows IAM best practices for any AWS resources it provisions or accesses in the customer's account.

Requirements:

No hardcoded AWS credentials in code, configuration files, or AMIs. IAM roles used instead of access keys wherever possible. IAM policies follow least privilege (no wildcard * permissions on actions or resources unless technically justified). Cross-account access uses IAM roles with external ID conditions (preventing confused deputy attacks). Service-linked roles used where available.

Common failures: IAM policies with Action: "*" and Resource: "*". Access keys embedded in CloudFormation templates or container images. Overprivileged IAM roles granting permissions far beyond what the product needs.

How to prepare: Audit every IAM policy your product creates or uses. Replace wildcards with specific actions and resource ARNs. Document the justification for every permission. Use the IAM Access Analyzer to identify overprivileged policies. See our AWS penetration testing guide for comprehensive AWS security testing.

Data Encryption

Requirements:

Data at rest encrypted using AWS KMS (customer-managed keys where possible). Data in transit encrypted using TLS 1.2+. S3 buckets with default encryption enabled. EBS volumes encrypted. RDS instances encrypted. Secrets stored in AWS Secrets Manager or Systems Manager Parameter Store (SecureString), not in plaintext configuration.

Common failures: Unencrypted S3 buckets. Database instances without encryption at rest. Secrets in environment variables or configuration files. TLS 1.0/1.1 still supported.

How to prepare: Enable encryption on every data store. Migrate secrets to Secrets Manager. Enforce TLS 1.2+ on all endpoints. Use AWS Config rules to detect unencrypted resources automatically.

Logging and Monitoring

Requirements:

CloudTrail enabled in all regions for API audit logging. VPC Flow Logs enabled. Application-level logging capturing security-relevant events. Log retention meeting compliance requirements (typically 1 year minimum). Logs stored in a separate, restricted account or bucket.

Common failures: CloudTrail not enabled in all regions. No application-level security logging. Logs stored in the same account without access restrictions. No log retention policy.

How to prepare: Enable CloudTrail in every region. Enable VPC Flow Logs. Implement application logging for authentication events, authorisation failures, data access, and configuration changes. Configure log retention policies. Store logs in a dedicated logging account with cross-account access restrictions.

Networking

Requirements:

Security groups follow least privilege (no 0.0.0.0/0 ingress on management ports). Public subnets used only for resources requiring direct internet access. Private subnets for databases, application servers, and internal services. Network ACLs providing additional defence. VPC endpoints used for AWS service access where available (reducing internet exposure).

Common failures: SSH (port 22) or RDP (port 3389) open to 0.0.0.0/0. Database instances in public subnets. All resources in a single public subnet. No VPC endpoints for S3 or other AWS services.

How to prepare: Restrict security group ingress to specific CIDR ranges. Move databases and internal services to private subnets. Implement VPC endpoints for S3, DynamoDB, and other AWS services your product accesses. Use AWS Security Hub to detect networking misconfigurations.

Resilience and Availability

Requirements:

Multi-AZ deployment for production workloads. Auto Scaling configured for compute resources. RDS Multi-AZ or Aurora for database high availability. S3 for durable storage. Backup strategy with tested restoration. Health checks configured for load-balanced resources.

Common failures: Single-AZ deployment. No Auto Scaling (fixed instance count). Single-AZ database without automated backups. No tested disaster recovery.

Operational Excellence

Requirements:

Infrastructure-as-code (CloudFormation, Terraform, CDK) for reproducible deployments. Automated deployment pipelines. Runbooks for common operational procedures. Monitoring dashboards for product health. Alerting for critical operational events.

Common failures: Manual deployment processes. No infrastructure-as-code. No monitoring or alerting. No operational documentation.

FTR Requirements Mapped to Compliance Frameworks

Many FTR requirements overlap with compliance frameworks you may already maintain.

If you're already SOC 2 certified, approximately 70% of FTR security requirements are covered. The AWS-specific gaps are typically: IAM policy specifics (least privilege at the AWS IAM level), VPC architecture (private subnets, VPC endpoints), and AWS-native service configuration (CloudTrail, encryption settings).

See our SOC 2 penetration testing guide and SaaS compliance audit readiness guide for building the compliance foundation that supports FTR.

For ISO 27001 and PCI DSS overlap, see our penetration testing compliance guide.

AWS FTR Preparation Checklist

IAM and Access Control

• No hardcoded AWS credentials in code, config, or images
• IAM roles used instead of access keys wherever possible
• Every IAM policy follows least privilege (no unnecessary wildcards)
• Cross-account access uses external ID condition
• IAM Access Analyzer run with no critical findings
• Service accounts have dedicated roles with minimum permissions
• Root account not used for operational access
• MFA enabled on all AWS console access

Data Protection

• S3 buckets encrypted with default encryption (SSE-S3 or SSE-KMS)
• S3 bucket policies block public access (unless explicitly required)
• EBS volumes encrypted
• RDS/Aurora instances encrypted at rest
• DynamoDB tables encrypted
• TLS 1.2+ enforced on all endpoints
• Secrets stored in Secrets Manager or Parameter Store (SecureString)
• No secrets in environment variables, code, or CloudFormation templates
• KMS key policies restrict access appropriately

Logging and Monitoring

• CloudTrail enabled in all AWS regions
• CloudTrail logs stored in separate restricted bucket/account
• VPC Flow Logs enabled
• Application security logging implemented (auth events, access failures, data access)
• Log retention policy defined and configured (minimum 1 year)
• CloudWatch alarms for critical operational metrics
• AWS Config enabled for configuration change tracking
• AWS Security Hub enabled for security findings aggregation

Networking

• Security groups follow least privilege (no 0.0.0.0/0 on management ports)
• Databases and internal services in private subnets
• Public subnets only for internet-facing resources (ALB, NAT Gateway)
• VPC endpoints configured for AWS services (S3, DynamoDB, etc.)
• Network ACLs provide additional segmentation
• No unnecessary public IP addresses assigned
• WAF configured on public-facing endpoints

Resilience

• Multi-AZ deployment for production
• Auto Scaling configured for compute resources
• Database high availability configured (Multi-AZ RDS or Aurora)
• Automated backups enabled with adequate retention
• Backup restoration tested within past 12 months
• Health checks configured for load-balanced resources
• Disaster recovery plan documented

Operations

• Infrastructure defined as code (CloudFormation, Terraform, CDK)
• Deployment pipeline automated (CI/CD)
• Operational runbooks documented
• Monitoring dashboard configured
• Alerting for critical events operational
• Tagging strategy implemented for cost and resource management

Application Security

• Web application penetration testing completed within past 12 months
• API penetration testing completed
• Critical and high vulnerabilities remediated
• Secure development lifecycle implemented
• Dependency scanning in CI/CD pipeline
• OWASP Top 10 vulnerabilities addressed
• Multi-tenant isolation verified through testing

Common FTR Failures and How to Fix Them

Failure 1: Overprivileged IAM Policies

The finding: IAM policies grant Action: "*" or Resource: "*" without technical justification.

Why it happens: Developers use broad permissions during development and don't restrict them for production. CloudFormation templates copied from examples with overprivileged policies.

Fix: Audit every IAM policy. Replace * with specific service actions (s3:GetObject, dynamodb:Query). Scope resources to specific ARNs. Use IAM Access Analyzer to identify overprivileged entities. Document justification for any remaining broad permissions.

Failure 2: Unencrypted Data Stores

The finding: S3 buckets, EBS volumes, or databases without encryption at rest.

Why it happens: Encryption not enabled at resource creation. Legacy resources created before encryption was standard.

Fix: Enable default encryption on all S3 buckets. Encrypt EBS volumes (migrate data to encrypted volumes if necessary). Enable encryption on RDS/Aurora instances (requires snapshot and restore for existing unencrypted instances). Use AWS Config rules to detect unencrypted resources.

Failure 3: Exposed Secrets

The finding: AWS access keys, database passwords, or API keys in source code, environment variables, or configuration files.

Why it happens: Quick development practices embedding secrets for convenience. Environment variables used as "good enough" secret storage.

Fix: Migrate all secrets to AWS Secrets Manager or Parameter Store SecureString. Update application code to retrieve secrets at runtime. Implement pre-commit hooks (gitleaks, truffleHog) preventing secrets from entering repositories. Rotate any secrets that were previously exposed. See our cloud security testing guide for comprehensive cloud security validation.

Failure 4: Open Security Groups

The finding: SSH (22) or RDP (3389) open to 0.0.0.0/0. Database ports accessible from the internet.

Why it happens: Security groups opened for debugging and never restricted. Default security group rules not reviewed.

Fix: Restrict management port access to specific CIDR ranges (office IPs, VPN ranges). Use Systems Manager Session Manager for SSH access (eliminates the need for open SSH ports). Move databases to private subnets with no direct internet access.

Failure 5: Missing CloudTrail

The finding: CloudTrail not enabled in all regions, or logs not adequately protected.

Why it happens: CloudTrail enabled only in the primary region. Logs stored in the same account without access restrictions.

Fix: Enable CloudTrail in all regions (organisation trail if using AWS Organizations). Store logs in a dedicated logging account or bucket with restrictive access policies. Enable log file validation. Configure lifecycle policies for log retention.

Failure 6: Single-AZ Deployment

The finding: Production workloads running in a single Availability Zone without multi-AZ resilience.

Why it happens: Cost optimization. Development architecture carried into production.

Fix: Deploy across multiple AZs. Configure Auto Scaling groups spanning AZs. Enable Multi-AZ for RDS. Use ALB distributing traffic across AZs.

Security Testing for FTR Readiness

Why Testing Matters for FTR

The FTR self-assessment evaluates your architecture and configuration. It doesn't test whether your security controls actually resist attacks. A properly configured IAM policy that still allows privilege escalation through a confused deputy scenario passes self-assessment but fails under testing. Penetration testing validates what self-assessment describes.

What to Test Before FTR Submission

AWS infrastructure security. Cloud penetration testing evaluating IAM policies, S3 bucket configurations, security groups, encryption, and cross-account access. Testing validates that FTR requirements are not just configured but effective.

Application security. Web application testing and API testing ensuring the SaaS product itself is secure. FTR reviewers evaluate product security alongside infrastructure.

Multi-tenant isolation. For SaaS products: systematic IDOR/BOLA testing verifying tenant data isolation. Cross-tenant access attempts across every endpoint. See our SaaS penetration testing guide for methodology.

Authentication and authorisation. Authentication bypass testing. OAuth flow validation. Session management assessment. Privilege escalation testing.

Recommended Testing Approach

Phase 1: Automated AWS assessment. Run AWS-native tools (Security Hub, IAM Access Analyzer, Config rules) to identify configuration gaps against FTR requirements.

Phase 2: Manual penetration testing. Expert-led manual testing of the application and infrastructure. Business logic testing for SaaS-specific vulnerabilities. AppSecure provide comprehensive SaaS and AWS security testing for companies preparing for FTR.

Phase 3: Remediation and retesting. Fix identified issues. Retest to confirm fixes. Submit for FTR with testing evidence demonstrating security validation.

For evaluating testing providers, see our quality evaluation guide.

Beyond FTR: Maintaining Marketplace Listing

Ongoing Requirements

FTR isn't one-time. AWS periodically re-evaluates listed products. Major version updates require re-review. Maintaining your listing requires ongoing security discipline.

Continuous compliance: Keep SOC 2 current. Maintain audit readiness. Annual penetration testing. Configuration drift monitoring.

Continuous testing: Continuous penetration testing and PTaaS ensure your product security doesn't degrade between FTR reviews. See our continuous vs annual pentest comparison.

Security improvements: SaaS security vulnerabilities evolve. See our SaaS security vulnerabilities analysis for current threat patterns. Vulnerability management ensures ongoing remediation.

AWS Marketplace and Regional Considerations

US Market

The primary AWS Marketplace buyer base. US enterprise procurement teams increasingly prefer Marketplace for vendor management simplification, consolidated billing, and pre-vetted security (FTR). Passing FTR signals security maturity to US buyers.

UAE Market

UAE enterprises using AWS are growing rapidly. AWS Marketplace listings accessible to UAE buyers must consider data residency requirements. Products storing data in the ME (Bahrain) region satisfy many UAE data sovereignty expectations.

Singapore Market

Singapore financial institutions using AWS for regulated workloads require products meeting MAS TRM guidelines. FTR compliance plus MAS-aligned security testing strengthens your position with Singapore financial buyers. See our Singapore security audit guide.

How AppSecure Supports FTR Preparation

AppSecure provides the security testing that validates FTR readiness and strengthens your Marketplace listing.

AWS Infrastructure Testing. Cloud penetration testing specifically for AWS environments: IAM policy exploitation, S3 bucket security, security group validation, cross-account access testing, and encryption verification.

SaaS Application Testing. Web application and API penetration testing validating product security. Multi-tenant isolation testing. Business logic assessment.

Compliance-Mapped Reports. Findings mapped to FTR requirements, SOC 2, and ISO 27001. One engagement providing evidence for FTR submission and compliance audits.

SaaS security assessment and application security assessment for comprehensive coverage. Offensive security testing for end-to-end validation.

Zero False Positives. Every finding validated. 3-Week Delivery. 90-day support. Complimentary retesting. Continuous testing and PTaaS maintaining ongoing FTR readiness.

Contact AppSecure:

• Schedule FTR Readiness Testing
• SaaS Security Assessment
• AWS Penetration Testing Guide

Frequently Asked Questions

1. What is the AWS Foundational Technical Review (FTR)?

The AWS FTR is a technical assessment required for products listing on AWS Marketplace. It evaluates whether your product follows AWS Well-Architected Framework best practices across security, reliability, performance, and operational excellence. The review covers IAM and access control, data encryption, logging and monitoring, networking, resilience, and operational practices. Products must pass the FTR before appearing in AWS Marketplace.

2. What are the main FTR security requirements?

Key security requirements include IAM policies following least privilege (no unnecessary wildcard permissions), data encrypted at rest and in transit (KMS, TLS 1.2+), secrets in Secrets Manager (not in code or environment variables), CloudTrail enabled in all regions, VPC networking with private subnets for databases, security groups restricting access to minimum necessary ports and sources, and multi-AZ deployment for resilience.

3. How long does FTR preparation take?

Twelve weeks from initial self-assessment to FTR submission for organisations starting from scratch. Six to eight weeks for organisations with existing SOC 2 or ISO 27001 certification because 70%+ of FTR requirements overlap with these frameworks. The timeline includes self-assessment, remediation, security testing, retesting, and submission.

4. What are the most common FTR failures?

The six most common failures are overprivileged IAM policies (wildcard permissions), unencrypted data stores (S3 buckets, databases, EBS volumes), exposed secrets (credentials in code or environment variables), open security groups (management ports accessible from the internet), missing CloudTrail (not enabled in all regions), and single-AZ deployment (no resilience). All are preventable through the preparation checklist.

5. Does SOC 2 help with FTR preparation?

Yes. Approximately 70% of FTR security requirements overlap with SOC 2 Trust Services Criteria. IAM access control maps to CC6. Encryption maps to CC6.7. Logging maps to CC7. Change management maps to CC8. SOC 2 certified organisations have a significant head start on FTR. The remaining gaps are AWS-specific: IAM policy details, VPC architecture, and AWS-native service configuration.

6. Do I need penetration testing for FTR?

The FTR doesn't explicitly mandate penetration testing, but testing validates that FTR requirements are not just configured but effective. IAM policies that pass self-assessment may still allow privilege escalation under expert testing. Encryption that's configured may have implementation gaps. Penetration testing provides the evidence that your product's security works in practice, strengthening your FTR submission.

7. What is the difference between FTR and SOC 2?

FTR is AWS-specific: it evaluates your product against AWS Well-Architected Framework requirements for Marketplace listing. SOC 2 is an industry-standard audit evaluating trust services criteria (Security, Availability, Confidentiality). FTR is a one-time review (with periodic re-evaluation). SOC 2 is an annual audit. FTR focuses on AWS architecture. SOC 2 covers organisational security broadly. Most SaaS companies need both: SOC 2 for customer trust and FTR for AWS Marketplace listing.

8. Can I list on AWS Marketplace without passing FTR?

No. The FTR is a mandatory requirement for all products listing on AWS Marketplace. Products that don't pass cannot be listed. Products with conditional approval must remediate findings within defined timelines. There is no alternative path to Marketplace listing that bypasses the FTR.

9. How do I handle secrets management for FTR?

Migrate all secrets (AWS access keys, database passwords, API keys, encryption keys) to AWS Secrets Manager or Systems Manager Parameter Store (SecureString type). Update application code to retrieve secrets at runtime. Remove secrets from source code, environment variables, and CloudFormation/Terraform templates. Implement secret rotation. Use pre-commit hooks to prevent secrets from entering repositories. Test that no secrets are exposed through application responses or error messages.

10. What happens after FTR approval?

After approval, your product is listed on AWS Marketplace. Maintain FTR compliance through ongoing security practices: keep infrastructure-as-code current, maintain encryption and IAM policies, continue logging and monitoring, conduct annual penetration testing, and maintain compliance certifications. AWS periodically re-evaluates listed products. Major version updates require re-review. Continuous security testing ensures your product remains FTR-compliant.