Why Hyperswitch security hardening decides your PCI DSS scope
Hardening decides how much of your environment a PCI DSS assessor will treat as in scope, and it is the main lever you hold to limit exposure of card data, the encryption service and processor credentials. A team that self-hosts Hyperswitch owns all of these, so the security of each component falls to your own staff. The core question for the assessment is which systems can touch cleartext card data or the keys that protect it, and which controls prove that only the intended systems can. Answering that question is the first step of hardening, and the rest of this section explains why it takes more work than a default install suggests.
Hyperswitch is a set of components, and each needs different controls. The card vault is a separate Rust service that stores card data, and the encryption service manages the keys that protect it. Router and Scheduler (Producer and Consumer) handle payment flow and background work. PostgreSQL runs with a primary and a replica, Redis serves caching and the scheduler queue, and the Control Center gives merchant users access to payments and settings. Each has its own network exposure, secrets, access paths and logging needs. Default Helm installs give you a working starting point, and that starting point still needs review against your own requirements before any card data reaches it.
The vault model you choose sets which of these components enter scope. Hyperswitch documents three self-hosted options: the native Hyperswitch Vault, self-hosted orchestration with an external PCI vault provider such as VGS or Tokenex, and self-hosted orchestration with the SaaS Hyperswitch Vault. The Hyperswitch docs state that in the self-hosted, in-house PCI model, the merchant is fully responsible for PCI DSS certification and data handling. In that model, the vault, the encryption service, the database holding vault data, the network paths between them and the logging around them all fall into your assessment. Settle the vault model before you harden, because the boundary you draw determines which controls you build first.
Three factors make this harder than it looks. First, the number of components means each service needs its own review of ingress, egress, service accounts and privileges. Second, secrets sit in several places at once, including Helm values, Kubernetes secrets and cloud secret services, so one copied value in a values file can undo a control applied elsewhere. Third, Hyperswitch ships roughly monthly minor releases, and the GitHub releases page lists v1.126.0, v1.127.0 and v1.128.0, each with a compatibility matrix for Control Center and web client versions. A release can change configuration, add required dependencies or alter the attack surface, so the hardening baseline keeps moving. Plan a repeatable check for each upgrade rather than treating hardening as a one-time project.
Before you size the work, confirm three things with your team and your assessor. List which components hold or can reach card data, keys or processor credentials, and record where each secret is stored today. Decide which vault model the business will run and document the scope boundary it creates. Then set a review trigger for every monthly release that covers configuration changes, new dependencies and any change to the compatibility matrix. These three outputs give you a baseline you can defend and a process you can repeat.
Which Hyperswitch components carry security controls
Hyperswitch runs as a set of services, data stores and client surfaces, and each one touches data that falls inside your hardening scope. The cards below describe what each component does, what it handles and what to check. Exact configuration keys and network ports change between releases, so confirm them in the release documentation for the version you run.
Rust core app server (Router)
The Router is the Rust core app server. It handles routing, retries, vaulting and observability, so it sees payment requests, processor responses and the calls that pass card data onward to the vault. Check which endpoints accept inbound traffic, how merchant API keys are authenticated, what reaches application logs, and which services it may call. Confirm each setting against the release docs for your version.
Scheduler (Producer and Consumer)
The Scheduler runs as two app services, a Producer and a Consumer, that handle scheduled, asynchronous work for payments. It reads from and writes to the Redis scheduler queue and to PostgreSQL, so it holds payment-related records even when no client is waiting on a response. Check that the Producer and Consumer use separate credentials, that queue messages carry no card data, and that scheduled jobs resume safely after a restart.
Card vault (locker)
The card vault, also called the locker, is a separate Rust service in its own repository. The architecture docs describe it as built for PCI DSS requirements, and it is where card data is expected to live, so its isolation and access controls drive your PCI DSS scope. Check its network isolation, who can reach its database, how access is logged, and which systems hold only tokens. Those answers determine which systems auditors treat as in scope.
Encryption service for key management
The encryption service handles encryption and key management for sensitive data in the platform. A compromise of its keys would expose data protected elsewhere, so treat it as the most sensitive service in the deployment. Check where keys are generated and stored, who can request decryption, how key access is logged, and how keys are rotated. Confirm the key management model against the release docs for your version.
PostgreSQL and Redis data stores
PostgreSQL runs in a master and replica setup and holds the platform's persistent records. Redis serves as the cache and as the scheduler queue, and both sit behind the Router and Scheduler. Both may hold payment metadata that needs protection. Check that database and cache access use separate credentials, that TLS is enforced on connections, that the replica has the same access controls as the master, and that Redis is not reachable from outside the cluster network.
Control Center and client SDKs
The Control Center is the merchant dashboard for connecting processors and managing payments, refunds and disputes. Client SDKs for web, Android, iOS, React Native and Flutter start payment flows in customer browsers and apps. The Control Center supports OpenID Connect single sign-on only, with no SAML and no SCIM provisioning, so check how users are invited, how roles are assigned in Hyperswitch, and that SDK traffic to the Router uses TLS.
Decisions that set your hardening baseline
This table compares the four decisions that most shape the Hyperswitch security baseline: vault model, key custody, data store hosting and Control Center exposure. Read each row for what changes in network design, key custody and the evidence you must keep, then confirm the choices with your assessor before building.
| Decision | Option and when it fits | What changes operationally |
|---|---|---|
| Card vault model | Native Hyperswitch Vault in-house. Fits teams that will own PCI DSS certification and data handling end to end. | Your team carries the cardholder data environment network segmentation, vault key rotation and the full evidence set. |
| Card vault model | External PCI vault such as VGS or Tokenex. Fits teams that want card storage handled by a specialist provider. | Network design centers on controlled egress to the vault provider and tokenization paths, with provider attestation kept as third-party evidence. |
| Card vault model | SaaS Hyperswitch Vault with self-hosted orchestration. Fits teams that want less card storage inside their own estate. | Your network must allow secured calls to the hosted vault, and you retain evidence of the integration boundary and vendor responsibilities. |
| Encryption keys | Key management service in your cloud account. Fits teams that already run centralized key custody with audit logging and access policies. | Key custody follows your existing key policies, rotation schedules and access reviews, and key access logs become primary assessment evidence. |
| Encryption keys | Self-managed secret store. Fits teams with mature secret operations who accept running key storage and its availability themselves. | You own key backup, unseal or recovery procedures and access logging, so these controls must be documented and tested. |
| Redis and PostgreSQL hosting | Inside the Kubernetes cluster. Fits teams with strong cluster operations and a need to keep all components in one network boundary. | Backups, patching, encryption at rest and network policies for these stores are your responsibility, along with their place in scope. |
| Redis and PostgreSQL hosting | Managed services in your cloud account. Fits teams that want provider-run patching and backups within their own account. | Private endpoints, IAM access, encryption configuration and provider logs become the controls to verify and retain. |
| Control Center exposure | Corporate network only. Fits teams whose merchant staff work on fixed networks or through a VPN. | Ingress stays private, and access depends on network controls plus Control Center authentication, which supports OpenID Connect single sign-on only. |
| Control Center exposure | Broader internet path behind a web application firewall and identity controls. Fits teams with remote staff and no private access option. | Requires TLS configuration, rate limiting, login monitoring and session controls, and it widens the attack surface your testing must cover. |
How to harden a Hyperswitch deployment in sequence
This sequence takes a self-hosted Hyperswitch deployment from an undefined data flow to documented controls around the card vault, keys, credentials, transport, logs and admin access. Each step builds on the one before it and closes with a check the team can repeat. The output is a control register that names owners and evidence locations for a PCI DSS assessment.
Define the cardholder data flow and boundary
Map every path card data takes through Hyperswitch, from the client SDK through Router and the card vault and encryption service to each processor. Draw the boundary around the vault and encryption service, and list every system that touches card data or tokens. The platform or security lead owns the diagram. The step closes when each system inside the boundary has a named owner and no unmapped data path remains.
Segment the network and restrict vault egress
Place the card vault and encryption service in dedicated namespaces or subnets, with default-deny policies and only the flows the data map requires. Restrict outbound traffic from the vault so it reaches only the components it must call. Keep Router, Scheduler, PostgreSQL and Redis on explicit, documented paths. The platform team applies and tests the rules. The step closes when a test from an out-of-scope workload to the vault fails and each permitted flow succeeds.
Store encryption keys in a managed key store
Keep encryption keys in a managed key store, and grant key use only to the encryption service identity. Write down the key hierarchy: which key protects which data, where key-encryption keys sit, and who can request a rotation or a recovery. Confirm the exact key store integration and key settings in the self-hosting docs for your release. The security engineer closes the step with a documented hierarchy and an access test showing that no other identity can use the keys.
Secure credentials and rotate API keys
Remove database, Redis, processor and key credentials from plain Helm values and load them from a secrets manager through service accounts with least privilege, one per workload. Set up API key issuance, scoping and storage, then write a rotation procedure that adds the new key, moves clients over, and retires the old key without downtime. The platform team runs one rotation in a non-production environment first. The step closes when a search of chart values and repositories finds no live credentials and a rotation completes with no failed payment calls.
Enforce TLS between services and processors
Terminate TLS at the ingress and enforce it between Router, Scheduler, the vault, the encryption service, PostgreSQL, Redis and each processor connection, where the release supports it. Define who issues and renews certificates, where they are stored, and what happens on expiry. Confirm certificate handling and protocol settings against the self-hosting docs for your release. The network engineer closes the step by testing each hop and recording the certificate authority, renewal path and expiry alert.
Keep card data and secrets out of logs
Configure application, audit and access logs so card numbers, tokens, key material and credentials are never written to them. Confirm which fields the platform emits by default, and mask or drop sensitive fields at the source where the logger allows it. Ship logs to a protected store with restricted read access and retention set by your policy. The platform and security teams close the step by sending test card numbers and a seeded token through the system and searching the log store with zero matches.
Lock down the Control Center access path
Restrict who can reach the Control Center and route access through a controlled network path, such as a private ingress or VPN. Set up single sign-on with OpenID Connect as described in the Hyperswitch Control Center SSO and identity integration topic. Keep roles managed inside Hyperswitch, since the platform does not map roles from the identity provider. Remove shared accounts and review every invited user. The security lead closes the step with a user list matching the approved roster and a denied-access test from outside the approved path.
Record each control with owner and evidence
Build a control register that lists each control from the previous steps, its owner, the system it covers, how it is tested, and where the evidence lives, such as configuration exports, test output, change tickets or log samples. Review the register with the compliance lead and agree a review cadence your team will own. DeployOpen prepares this evidence for assessments, but independent auditors and certification bodies issue any opinion. The step closes when a reviewer can open every evidence location without asking the author.
Controls to put in place for the card vault, keys and secrets
These six controls protect stored card data in a self-hosted Hyperswitch deployment: the card vault and its database, the encryption service and its keys, secrets, API keys, transport encryption and logs. Each control is described in plain language by the risk it reduces, the evidence an assessor will ask for and the responsibility you keep. Confirm how these controls map to PCI DSS requirements with your QSA or assessor before you rely on that mapping.
Network isolation for the card vault
The card vault (locker) is a separate Rust service with its own database, so it should not share a flat network with the router, Control Center or general workloads. Allow inbound traffic to the vault only from the services that must call it, limit database access to the vault alone, and deny any outbound path you have not documented. This reduces the risk that a compromised dashboard or scheduler pod reaches card storage directly. Assessors typically ask for network diagrams, cluster network policies or security group rules, and a tested list of permitted flows. Your team owns those rules and the review cycle that keeps them current.
Key custody and separation of duties
The encryption service holds the keys that protect stored card data, so who can generate, read, rotate or back up those keys matters as much as where they are stored. Name the key custodians, keep platform administrators apart from people who can use or unwrap keys, and log every key operation. This reduces the risk that one engineer with broad cluster access can export key material unnoticed. Assessors usually ask for a key inventory, custodian role assignments, approval records and rotation logs. Your responsibility is the custody model and the key management service you select and configure.
Secrets storage and rotation
Database credentials, encryption service access, connector credentials and Control Center secrets should live in a dedicated secrets manager and reach workloads at runtime. Keep copies out of Helm values files, container images and repository history. This reduces the risk that a leaked configuration file exposes a working credential for months. Assessors commonly ask for a secrets inventory, access policies, rotation records and evidence that an old credential stopped working after rotation. Your team chooses the secrets manager, sets rotation intervals for each secret and rehearses rotation so it does not cause an outage. Confirm the intervals with your assessor.
API key lifecycle for merchant and service calls
Merchant and service calls into Hyperswitch authenticate with API keys, which must be created, scoped, rotated and revoked on a defined schedule and whenever an integration or staff member changes. Issue a separate key for each integration, limit it to the operations it needs, and keep a register that names an owner for every key. This reduces the risk that a key from a retired integration still works. Assessors usually ask for the key register, creation and revocation logs and proof that a revoked key is rejected. Your team owns the issuance process, expiry rules and offboarding steps.
TLS for internal and external paths
Encrypt traffic from SDKs and clients to the router, and between the router, scheduler, card vault, encryption service, databases and Redis. Encrypt connector calls to external processors too. Use certificates from a managed issuer, accept only current TLS versions and require certificate verification on every client. This reduces the risk that card data or tokens are read or altered in transit inside the cluster. Assessors typically ask for TLS configuration scan results, a certificate inventory with expiry dates and the ingress and service-to-service settings. Your team owns certificate issuance and renewal, and confirms which TLS versions each connector supports.
Logging hygiene that excludes card data and secrets
Router, scheduler and vault logs support troubleshooting and incident response, but they can also become a second copy of card data or credentials. Define which fields are masked or dropped before a log line leaves the service, restrict who can read logs and set retention limits. Test the rules in staging with test card numbers and dummy secrets to confirm nothing sensitive is written out. This reduces the risk that card numbers or keys sit in a log store with wider access than the vault. Assessors usually ask for logging configuration, redaction rules, sample log extracts, access lists for the log platform and retention settings. Your team owns those rules and their testing.
How to test that the hardening holds and fails safely
Verify each control in a non-production environment first, then repeat the same checks in production under a change record. The non-production environment should match production in its Hyperswitch version, Helm chart values, Kubernetes namespace layout, network policies and card vault model, so that a passing result means something. Write each test down before running it, with the expected result and the evidence you will keep. In production, limit tests to read-only checks or to controlled test transactions, name an approver and a time window in the change record, and confirm that the running release matches the version and Control Center compatibility matrix you tested.
Start with network policy tests. From a pod in an unauthorized namespace, and from an application pod that has no business reaching the card vault, attempt connections to the vault and the encryption service on their service ports. The expected result is a refused or dropped connection, and the attempt should appear in your logs or flow records. Then run the same connection from the router pods that should be allowed, so you can see the policy permits the intended path. Repeat this for the Control Center and the Scheduler. Also confirm that the encryption service accepts requests only from its approved workload identities by presenting a workload identity that is not on the allowlist. How identity is enforced depends on your design, so ask your platform team to document the mechanism before the test.
Scan for secrets and card-like data in four places: container images, Helm values files, rendered manifests and log output. Use a scanner configured for payment card number patterns and common credential formats, and test it first against a planted sample so you know it detects what it should. Generate log traffic in non-production with synthetic test cards only, never with live card data. For TLS, check every hop: client to router, router to the card vault, router to the encryption service, router to PostgreSQL and Redis, the Scheduler to its dependencies, and the Control Center to the API. For each endpoint, confirm the certificate chains to the expected authority, the negotiated protocol and ciphers meet your policy, and no plaintext fallback exists.
Run the rotation drill in non-production before production. Rotate the encryption key and the API keys used by your services, then confirm that the old keys are rejected after cutover. Confirm also that data protected under the previous key can still be read during the window you have planned for re-encryption, and that the window closes on schedule. For fail-safe behavior, block the card vault or the encryption service with a network policy, or stop the key dependency, then submit test payments. A correct result is a payment that fails with an error returned to the client, with no card data written to PostgreSQL, Redis, the Scheduler queue, logs or any other store. Check that retries and routing fallback do not carry card payloads to another path or bypass the vault.
After any change to the hardening, run a penetration test or security test of the API and the Control Center. Scope the test to authentication and role enforcement in the Control Center, API key handling, input validation, and the network paths you checked above, and give the tester the architecture, test accounts and a change window. Retest any findings after the fixes are deployed. If your internal team lacks the time or independence for this work, DeployOpen's security testing services cover application and API testing and cloud and infrastructure testing, scoped in writing before work starts. The test results become evidence for your assessor, but an independent auditor or certification body must make the compliance determination.
What drives hardening effort and how to keep it down
This table lists the drivers that change how much hardening work a Hyperswitch deployment needs, why each one matters, and the levers that keep it manageable. Read each row as a scoping question: which choice multiplies the controls, and which one can be narrowed before the build starts. The main takeaway is that the vault model and the number of environments usually shape effort more than the number of connectors.
| Driver | Why it raises effort | How to reduce it |
|---|---|---|
| Number of environments | Sandbox, staging and production each need the same controls applied, configured and evidenced, so effort grows with every copy. | Use one hardened Helm baseline with per-environment values files. Confirm which environments will ever hold live card data. |
| Vault model | In the self-hosted, in-house PCI model the merchant carries full PCI DSS responsibility for certification and data handling, which adds the most evidence work. | Compare the in-house, external vault and SaaS vault options with your assessor before the build. If you keep the native vault, fence its network zone tightly from day one. |
| Processors and merchant API clients holding credentials | Each connector credential and each client API key needs secure storage, rotation, access review and an owner. | Standardize one secrets path for connector keys, issue separate keys per client, and keep a register that maps each credential to its owner and rotation date. |
| Existing key management and secrets tooling | If your cloud or data center already runs approved key management, the encryption service must integrate with it. If it does not, a tool must be selected and operated too. | Reuse approved tooling where the encryption service supports it. Confirm the integration path early and document the key hierarchy once. |
| Network zones and clusters | Each zone, cluster and boundary rule needs its own diagram, test and evidence. More boundaries mean more flows to prove. | Keep the card vault in a dedicated zone with few, documented flows. Limit clusters to what isolation actually requires. |
| Release cadence and retesting | Hyperswitch ships roughly monthly minor releases, and some add required dependencies such as Superposition (v1.124.0). Each upgrade can change controls and trigger retesting. | Define which controls are retested after each upgrade. Automate configuration and TLS checks, and read the compatibility matrix before scheduling an upgrade. |
| Auditor evidence format | Assessors may accept screenshots, exports, tickets or system-generated logs. Manual formats multiply collection work for every control. | Agree the evidence format, sampling approach and log retention with your assessor before the build. Generate configuration exports and logs automatically where possible. |
How hardening differs by deployment environment
Hyperswitch documents self-hosting with Helm charts on Kubernetes, with guides for local Minikube, AWS, GCP and Azure. This is the model most production teams will use, so most hardening work sits here: network policies between the router, scheduler, card vault and encryption service, secret objects for database and vault credentials, and TLS at ingress and between services. The cloud guides differ in how they provision load balancers, workload identity and managed databases, so controls that depend on those services change from one cloud to another.
- Network isolation: Restrict card vault traffic to the components that need it, and place the vault in its own namespace or node pool where your cluster supports that.
- Secrets: Replace chart defaults with secrets from your cloud key manager or an external secrets operator, and confirm how rotated values reach running pods.
- Managed services: Managed PostgreSQL, Redis and key services may be available on AWS, GCP or Azure. Confirm each one meets your encryption and logging requirements before you select it.
- Updates: Monthly releases arrive as chart and image versions. Mirror images into your own registry, scan them, and promote them through your normal change process.
- Scope of the Minikube guide: Treat the Minikube guide as a local learning path and build production clusters from the cloud guide that matches your provider.
Before go-live, confirm which chart values expose services publicly, which secrets the chart creates on its own, and which managed services your cloud account can enable for the vault.
The Docker-based setup is intended for local or evaluation work. It lets engineers run the stack on a workstation to learn the components and test integrations. Its defaults favor convenience, so it is a weak base for production controls. Hardening here focuses on keeping test data, test keys and local services away from anything that resembles production.
- Controls that change: Expect placeholder credentials, locally exposed ports and single-instance services. Replace credentials on any shared test machine and close ports you do not need.
- Managed services: Cloud key, secret and log services are generally not part of this setup. Local secret files are acceptable only for evaluation and must stay out of version control.
- Image updates: Developers typically pull images from the upstream registry. Pin image tags and record the version you tested so results can be reproduced.
- Data: Use synthetic card data and sandbox credentials only. The hosted sandbox is for testing only and is not a hardening target for production data.
- Version alignment: Follow the Docker steps in the self-hosting documentation for the exact version you pin, and confirm which services are meant for evaluation.
Before any environment built from this setup holds real payment data, rebuild it on the Kubernetes or restricted network model and rerun the controls described in the other tabs.
In an air-gapped or restricted network, the image pipeline, key store and log destinations must all be internal. No component can reach a public registry, a SaaS key service or a hosted log platform at runtime. Hardening starts with the supply chain: every image, chart, dependency and release note must be carried in through an approved transfer process before it can be deployed.
- Image pipeline: Mirror container images and Helm charts into an internal registry, and verify digests before admission to the cluster.
- Key store: The encryption service and vault keys must rely on an internal key management service or hardware-backed store. Confirm that no key operation falls back to an external cloud service.
- Log destinations: Send audit and application logs only to internal systems, and confirm that retention and access controls meet your own policy.
- Dependency updates: Set a scheduled process for bringing in PostgreSQL, Redis, container base image and Control Center package updates, including the security patches they carry.
- External calls: Ask Hyperswitch which external endpoints each release requires, including any new required service such as Superposition in certain versions, and confirm an internal equivalent exists for each one.
Before the first deployment, test the full upgrade path offline. An upgrade that depends on an outside download will stall in this model, and that delay can affect your change schedule.
What to monitor, rotate and document after go-live
After go-live, the hardening controls only hold if someone runs them on a schedule. The first recurring job is monitoring for four conditions: unexpected network paths to the card vault, failed authentication against the encryption service, API key use from unknown sources, and certificate expiry on TLS endpoints facing merchants, the Control Center and internal services. Each alert needs a defined owner and a baseline of expected sources, so the team can tell a new integration from an attacker. Before promising these alerts to an assessor, confirm which events your Hyperswitch deployment, cluster, network controls and identity provider actually emit, and where those logs are retained. Some of this telemetry will need to be built, not switched on.
Rotation needs one calendar that covers three groups: API keys issued to merchants and internal services, service credentials for PostgreSQL, Redis and the scheduler, and encryption key material used by the encryption service and the card vault. For each item, record the owner, the interval set by your key management policy, the procedure and the evidence produced. Confirm in the Hyperswitch documentation and with your key management provider how each key type can be rotated without downtime, and whether the encryption service can rotate its key while existing vault records stay readable. Key rotation touching the vault is the highest-risk change on the calendar, so rehearse it in a non-production environment first.
Restore testing proves that backups of key material are usable without making them easier to steal. Restore a copy of the relevant key material and database snapshot into an isolated environment, then confirm decryption works using a known test record and a pass or fail check. Never paste key values into tickets, chat or logs, and limit the people who can run the test, ideally with two people present. Destroy the restored copy when the test ends, and file the result, timestamp and operator as evidence. The test interval should follow the same policy as rotation, and a failed restore should open an incident, not a backlog item.
Patch intake turns Hyperswitch's roughly monthly minor releases into a controlled decision. For each release, read the compatibility matrix for Control Center and web client versions and the security notes, then decide whether to schedule an upgrade, defer it or apply a compensating control. Recent releases show why this step matters: the v1.124.0 release notes made Superposition a required configuration dependency, and deployments must have a Superposition service running before upgrading to that version. Any upgrade that touches Superposition belongs in the security review as well, covering its access controls, network path, configuration changes and logging. Do not treat a minor version number as a reason to skip intake.
The control register and the evidence library must stay current for the assessor. Each hardening control should map to an owner, a test procedure, the date of the last evidence and links to the relevant change or incident records, including monitoring alerts, rotation logs, restore tests and upgrade reviews. Keep the register in the same system the team already uses for change management, so evidence is created during the work rather than rebuilt before an assessment. DeployOpen can prepare systems, controls and evidence for an assessment, but independent assessors and certification bodies decide the outcome. Agree the evidence format and sampling expectations with your assessor early.
Questions teams ask before hardening a self-hosted Hyperswitch
How much effort does hardening a self-hosted Hyperswitch take, and what drives it?
Effort depends mainly on the vault model, the number of environments, and how far your deployment departs from the default. The card vault and encryption service need the most attention because they hold card data and key material, so network isolation, key management and access paths take longer to design than the application tier. The main drivers are whether you run the native Hyperswitch Vault or an external PCI vault provider, how many clusters and environments (development, staging, production) must match, how your secrets store and TLS certificates are already managed, and how much log data you must retain and route to a SIEM. Ask for a quote that lists each control area, the environments covered and the evidence you will receive at the end.
Can our own team harden a self-hosted Hyperswitch without outside help?
A team with Kubernetes, network security and payments experience can do much of the work internally, and the answer depends on who owns each control. Hyperswitch is open source under Apache 2.0, so you can read the configuration and build the controls yourself. The harder parts are the ones where a mistake is costly: vault isolation, key management, and the TLS and logging settings that an assessor will test. Check whether your team has scoped a PCI DSS assessment before and whether reviewers can check its work independently. Many organizations split the work, with internal staff making the decisions and running the controls while an outside team plans, implements and documents the hardening. Whichever path you choose, write down the estimate so you can compare it with a partner's written scope.
What does hardening need from our security, platform and payments staff?
Hardening needs security staff to set control requirements and review evidence, platform staff to build and run the network, secrets and cluster controls, and payments staff to confirm which flows touch card data and how connectors behave after changes. Security: define isolation boundaries, key custody, access reviews and log retention. Platform: own Kubernetes network policies, the secrets store, certificate management, PostgreSQL and Redis access, and backup restore tests. Payments: map which connectors, webhooks and stored tokens cross the vault boundary, and approve changes that could affect authorization. Each group needs time in design reviews and test windows. Confirm named people and their availability before work starts, since gaps in these roles often delay the work.
How does hardening affect our PCI DSS assessment, and who performs it?
Hardening produces the configuration, access and logging evidence that an assessor examines, but it does not set your PCI DSS scope or decide your compliance status. DeployOpen prepares systems, controls and evidence for compliance assessments. Independent auditors and certification bodies issue the reports and attestations. Under the self-hosted, in-house PCI model, Hyperswitch's documentation states that the merchant is fully responsible for PCI DSS certification and data handling. Under an external PCI vault or the SaaS vault, responsibilities and in-scope systems change, so the hardening scope changes with them. Confirm your scope with your qualified security assessor before design, and agree in writing which evidence the hardening work will produce.
Does hardening change after each monthly Hyperswitch upgrade?
Yes, part of the hardening work repeats after each upgrade, because the Hyperswitch project ships roughly monthly minor releases and each one can change configuration, dependencies or database migrations. Start by checking the compatibility matrix for Control Center and web client versions in the release notes. Then look for new required services. For example, the v1.124.0 release notes made Superposition a required configuration dependency, and deployments had to run that service before upgrading. After each upgrade, re-run the control tests for network isolation, secrets, TLS, logging and access, and review the release notes for changes to security-relevant settings. How much recurring effort this takes depends on how far your deployment has drifted from upstream and on whether a support retainer covers it.
What should a written hardening scope from a partner include?
A useful written scope names the systems, environments and control areas covered, and it states what is excluded. Ask the partner to specify which components are in scope, such as the Router, Scheduler, card vault, encryption service, PostgreSQL, Redis, Control Center and SDK endpoints. It should also state which vault model it assumes, which Kubernetes clusters, cloud accounts or data centers are included, and how secrets handling, API key rotation, TLS and logging controls will be designed and tested. Confirm the documentation and evidence you will receive, the access and approvals your team must provide, and what happens to findings outside the agreed scope. Ask whether future monthly upgrades are covered and whether a retainer applies. Fixed deliverables and timelines should be written down before work starts.
How DeployOpen scopes, hardens and hands over Hyperswitch security work
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Hyperswitch, that means reviewing your deployment, applying the security controls agreed in writing, and leaving your team with evidence and runbooks it can operate.
How we scope
- Map every Hyperswitch component in your deployment, including Router, Scheduler, PostgreSQL, Redis, card vault and encryption service
- Confirm which vault model you run, since it determines whether the card vault sits in your PCI DSS scope
- Agree written scope for network isolation, key management, secrets, API key rotation, TLS and logging before work starts
How we build
- Apply network isolation around the card vault and encryption service, restricting access to the services that need it
- Configure secrets handling, API key rotation and TLS settings in the Kubernetes or cloud environment you already operate
- Test each control against the agreed scope and record results so your team and assessors can trace what changed
How we hand over
- Deliver configuration, architecture notes and control evidence mapped to your PCI DSS assessment preparation
- Document the rotation schedule, key ownership, logging retention and on-call steps your team will run after handover
- Walk your engineers through the hardened setup and confirm they can perform rotation and restore steps unaided
How we support
- Review each Hyperswitch release for changes to security-relevant settings before you upgrade, including new required dependencies
- Offer ongoing support, upgrades and continuous testing as a retainer, priced separately from the fixed-scope engagement
- Confirm with your team how support hours, response paths and upgrade windows will work before the retainer starts
