Open source PAM for PCI DSS

How open source PAM supports PCI DSS access controls

A self-hosted bastion helps a team control and prove who reaches systems in the cardholder data environment (CDE) by centralizing least-privilege access, multi-factor authentication and session logs in one place. It does not make the environment compliant on its own. Assessors still test the process around the tool: how access is requested and approved, how accounts are reviewed, and whether the recordings are kept, protected and actually examined. The current baseline is PCI DSS v4.0.1, which the PCI Security Standards Council (PCI SSC) describes as the only active version after v4.0 was retired on 31 December 2024 (see the PCI SSC blog on v4.0.1). Because the PCI SSC does not enforce compliance, the individual payment brands decide which entities must validate and how, so confirm your obligations with your acquirer or brand contacts before scoping the project.

Your assessment is documented on official PCI SSC templates: either a Report on Compliance completed by a Qualified Security Assessor, or a Self-Assessment Questionnaire, each closed with an Attestation of Compliance (AOC). A certificate from a vendor or from DeployOpen does not count as validation. Your Qualified Security Assessor or internal assessor will decide which requirements the bastion covers and which ones depend on evidence from your own processes, such as quarterly access reviews under 7.2.4. Ask early whether the bastion and its session store are in scope, because a system that can reach the CDE is itself usually in scope. Document the gateway's administrators, its own access controls and its log retention as part of the assessment, not as an afterthought.

Start by mapping each access path into the CDE to a requirement before choosing a platform: who is allowed in, how they authenticate, and what evidence the bastion produces for each path. Confirm with your assessor which approach you will use for each requirement, whether the defined approach or a customized approach, since the customized route requires a documented targeted risk analysis and more assessor effort. Then run a short test: pick one production database, route one administrator through the bastion, and check that the session recording, the approval record and the MFA event can all be exported and handed to an assessor. If any of those three cannot be produced, fix the gap before rollout across the estate.

Which PAM platform fits a PCI DSS environment

JumpServer suits estates where administrators reach a mix of Windows and Linux systems through one web workspace. The project describes itself as a bastion host and PAM platform covering SSH, RDP, Kubernetes, databases and websites, which fits a cardholder data environment where administrators use browsers on both server types. Review the JumpServer pricing page before you size the deployment, because the edition tiers are set by asset count and by feature.

Community limits: The free self-hosted Community edition is listed for up to 5,000 assets in a standalone topology, with support through GitHub and the forum.
Approval and rotation features: Ticket and just-in-time approval workflows, password rotation, custom roles and SSO are listed as Enterprise features. These bear on the least-privilege and approval controls in requirement 7.
Database coverage: Oracle and SQL Server access are listed as Enterprise features, so confirm early whether your cardholder databases need them.
High availability: Standard and Pro tiers are listed with active-standby high availability, and LDAP HA is an Enterprise feature. Both matter if the bastion must stay reachable during an incident.
Installation footprint: The quickstart expects a clean 64-bit Linux server with at least 4 CPU cores and 8 GB of RAM, plus the installer's setup steps.

Confirm the current asset limits, protocol list and Enterprise feature matrix with JumpServer before you write the design, because these determine both the license and the number of bastion nodes.

Mapping PCI DSS requirements 7, 8.4 and 10 to bastion configuration

This table maps the PCI DSS requirements that govern privileged and remote access to the bastion settings that support them, with the evidence an assessor typically looks for. Read each row as a control objective, then as the configuration choice that meets it, and confirm the final mapping with your QSA or the assessor for your scope. The main takeaway is that the bastion covers the access path, while the access model, reviews and risk analysis remain process obligations that the platform only supports.

Requirement	What the function must do	How to configure it
7.2 access control model	Define an access control model that grants access by job function and least privilege, with documented approval for each privilege.	Define roles per job function in the bastion, map each role to specific servers, databases and Kubernetes namespaces, and require a recorded approval before a role is assigned.
7.2.4 user and privilege reviews	Review all user accounts and privileges, including third-party and vendor accounts, at least once every six months, and act on inappropriate access.	Export the bastion user, role and asset-permission lists on the review cycle, assign a reviewer who is not the account owner, and keep the signed results with the actions taken. Edition support for automated access reviews should be confirmed.
7.2.5 and 7.2.5.1 application and system accounts	Assign only the privileges these accounts need and review their access at a frequency set by the targeted risk analysis under 12.3.1.	Register service and system accounts as separate identities with their own roles, avoid sharing them between people, and set the review interval to the value recorded in your targeted risk analysis.
8.4.1 MFA for non-console admin access into the CDE	Require MFA for all non-console administrative access into the cardholder data environment.	Enforce MFA at the bastion gateway for every administrative login, including web and API paths. Phishing-resistant authentication alone does not satisfy this requirement, per PCI SSC FAQ 1596, so keep a second factor in the flow.
8.4.2 MFA for all CDE access	Require MFA for all access into the CDE, except accounts that use only phishing-resistant authentication (PCI DSS v4.0.1) and application or system accounts performing automated functions.	Route all user access through the bastion with MFA enforced. If passkeys are used, confirm they meet the FIDO2-compliant synced passkey position in PCI SSC FAQ 1595. Exclude automated service accounts only where they are documented as automated.
8.4.3 MFA for remote access from outside the network	Require MFA for remote network access from outside the entity's network, including access by third parties and vendors.	Make the bastion the only inbound path for vendor and remote engineer sessions, require MFA for each vendor identity, and time-limit vendor accounts. Phishing-resistant authentication alone does not satisfy 8.4.3 per PCI SSC FAQ 1596.
10 session logging	Record and retain audit logs for access to system components and the CDE, with enough detail to show who did what, when and from where.	Turn on session recording for every protocol the bastion proxies, forward session and login events to the central log platform, and restrict who can edit or delete recordings. Confirm retention periods with your own policy and assessor.
Scope of the bastion	The bastion itself is in scope when it stores, processes or transmits access into the CDE, or can affect its security.	Place the bastion in the CDE or a segment defined by your scoping exercise, apply the same hardening and logging to it, and document its role in your data flow diagram. Confirm the boundary with your QSA before deployment.

Open-source platforms that fit PCI DSS access control

PCI DSS access controls depend on three layers working together: a gateway that brokers every administrative session into the cardholder data environment, an identity provider that enforces MFA, and a recording layer that produces the logs Requirement 10 expects. The cards below cover the gateway options, the identity provider and the license facts that decide which pieces you can run without a paid edition.

JumpServer as a bastion

JumpServer is a GPL-3.0 PAM platform covering SSH, RDP, Kubernetes, databases and web access from one workspace. The Community edition is free for up to 5,000 assets in a standalone topology, which can cover a single-site cardholder environment. Confirm whether your asset count stays within that limit, and whether you need high availability or approval workflows, which the pricing page places in Enterprise tiers. Ask which session recording and retention settings you control in each edition.

Teleport for short-lived access

Teleport issues short-lived certificates for SSH, Kubernetes and databases, so engineers avoid long-lived shared keys that are hard to tie to a person. Session recording with playback is included in both editions. The Community Edition license applies only to organizations with fewer than 100 employees and under $10,000,000 in annual revenue, so most card data environments will need a commercial license. Confirm that threshold with your counsel before you design around Community.

Apache Guacamole for vendor sessions

Apache Guacamole is a browser-based gateway for RDP, SSH and VNC, so a vendor can reach a specific host without a client install or a full VPN. This suits support vendors who need one system for one window of time. Because the gateway can inject credentials, the vendor never sees the stored password. Confirm which recording, approval and identity integrations your chosen deployment provides, since these are not all included by default and must be verified against your version.

Keycloak for MFA and SSO

Keycloak is an Apache-2.0 identity provider that supports OpenID Connect, SAML 2.0 and LDAP or Active Directory federation, so it can enforce MFA at the gateway for every administrative login. Version 26.8.1 was published on October 13, 2026. PCI DSS 8.4.1 and 8.4.3 need MFA on non-console administrative and remote access, and 8.4.2 extends it to all access into the CDE. Confirm which second factors you enable and whether phishing-resistant authentication is used, because PCI SSC FAQ 1596 says it alone does not satisfy 8.4.1 or 8.4.3.

ZITADEL or authentik as alternatives

ZITADEL is AGPL-3.0 and lists SSO, MFA, passkeys (FIDO2 and WebAuthn), OpenID Connect and SAML 2.0. authentik is MIT licensed except the authentik/enterprise directory, which carries a separate enterprise license. Either can serve as the identity provider behind the bastion if your team prefers its operating model. Confirm which features you need sit outside the enterprise directory, and check the AGPL-3.0 obligations with your legal team before modifying either product.

Where scoping the bastion into the CDE matters

A bastion that authenticates or proxies into the cardholder data environment usually falls inside the assessed scope. Once the gateway is the only path for administrators, vendors and engineers to reach CDE systems, an assessor will treat it as a system that can affect the security of the CDE. That means it needs the same hardening, patching, logging and access controls as the systems behind it, and its administrators need the same MFA and least-privilege treatment under Requirements 7 and 8. Teams that deploy a bastion as a convenience tool outside the CDE boundary often discover this only during assessment, when the gateway has already become the main control path.

Segmentation is the design decision that determines how large that scope becomes. Place the gateway in its own network zone, allow it only the specific ports and destinations needed for the protocols in use (for example SSH to named hosts and database ports to named servers), and block every other route from the gateway into the CDE. Document each data flow between the user network, the gateway, the target systems and the logging platform, and keep that diagram current. Confirm with your QSA or assessor, before any design work starts, where they will draw the boundary, whether the gateway can be placed outside it with controlled paths, and what evidence they will want for those paths.

Session recordings deserve separate attention. If an administrator's session displays primary account numbers, for example in a database query result or a support screen, the recording stores cardholder data and sits in scope with its storage, backups, search index and access logs. Decide whether recordings capture full keystrokes and screen output or only command metadata, and whether sessions touching the CDE can be configured to avoid displaying card data. Restrict who can play back recordings, log those playbacks, and confirm retention and encryption settings for the recording store with your assessor before rollout, because changing them later can force rework across the whole record set.

Evidence assessors ask for from a PAM bastion

This table maps each piece of evidence a QSA or internal assessor typically asks for to the system that produces it: the identity provider, the bastion, the SIEM or the assessment documents. Read it as a checklist of what to export and retain before the assessment starts, and note that the bastion alone rarely covers every row.

Evidence	Which component produces it	What to confirm before the assessment
Account and role lists with named owners	Identity provider for user and group membership, bastion for roles and resource permissions	Each account maps to one person or a documented service owner, with shared and generic accounts identified
Approval records for privileged access	Bastion access request and approval workflow, or a linked ticketing system	Confirm which approval steps are native to your edition and which rely on the ticketing tool
Six-monthly review results (7.2.4) with management acknowledgment	Bastion and identity provider exports of accounts and privileges, plus signed review records kept outside the tools	Acknowledgment by management is a process record, so confirm where the signed sign-off is stored
Review of application and system account access (7.2.5.1)	Bastion or vault inventory of service accounts, with the review frequency from the targeted risk analysis	Confirm the risk analysis document exists and sets the frequency used for the review
MFA configuration for CDE access (8.4.1, 8.4.2, 8.4.3)	Identity provider MFA policy and bastion authentication settings for each access path	Confirm MFA applies to every access path, including console and remote vendor access, and check phishing-resistant method rules
Remote vendor and third-party access records	Bastion session records and access request history, with VPN or remote access logs from the network layer	Confirm vendor accounts are time-limited and that third-party MFA is enforced under 8.4.3
Session logs and recording retention settings	Bastion session recordings and command logs, forwarded to the SIEM for correlation	Confirm recording retention periods, storage location, access controls on recordings and log integrity protections
Assessment documents (SAQ or ROC with AOC)	Prepared by the entity with its assessor; the bastion supplies only supporting evidence	The AOC is issued through PCI SSC templates by the assessor or entity, not by the tooling vendor

What the bastion alone does not satisfy

A self-hosted bastion covers much of the access control and logging work in PCI DSS, but several requirements depend on process, documented decisions and assessment evidence that no software provides. The cards below list the gaps that most often surface in an assessment of a PAM deployment in the cardholder data environment.

Six-monthly account reviews need sign-off

Requirement 7.2.4 expects all user accounts and privileges, including vendor accounts, to be reviewed at least once every six months, with inappropriate access addressed and management acknowledging the results. The bastion can produce the access lists, but the review itself is a documented process with named reviewers and a record of management acknowledgment. Check that your reviews produce a signed output that an assessor can sample, and that vendor accounts are included in the same cycle.

Customized approach requires a targeted risk analysis

If you meet a requirement through the customized approach instead of the defined approach, the standard expects a documented analysis showing how your method meets the stated objective. For application and system account reviews, Requirement 7.2.5.1 ties the review frequency to a targeted risk analysis under Requirement 12.3.1. A bastion setting that looks equivalent to the defined approach still needs this written justification, and an assessor will ask for it.

Phishing-resistant login does not replace MFA

PCI SSC FAQ 1596 states that phishing-resistant authentication alone does not satisfy Requirements 8.4.1 or 8.4.3. A passkey or hardware key at the bastion login can still need a second, separately documented MFA factor for non-console administrative access and remote vendor access. Confirm with your assessor how each access path is authenticated, and map each path to a 8.4 sub-requirement before you configure the identity provider.

Payment brands decide who must validate

The PCI SSC does not enforce compliance or impose penalties. The individual payment brands decide which entities must comply and validate, and they run any enforcement programs. Your acquirer or payment brand rules therefore set the scope and the validation level for the bastion project, and a platform vendor cannot determine them for you. Ask your acquirer which validation type applies before you define the CDE boundary.

No certificate replaces the AOC

A training certificate, a platform vendor letter or a certificate that a product was installed does not validate PCI DSS compliance. Validation comes from a Report on Compliance completed by a Qualified Security Assessor, or from a Self-Assessment Questionnaire, each with an Attestation of Compliance. Plan the evidence pack around the required templates, and do not present vendor or implementation certificates as proof of compliance to your assessor or acquirer.

Shared accounts and unmanaged service credentials

A bastion records who opened a session, but it does not stop a shared administrator login or a hard-coded password in a script from bypassing it. Such credentials still need inventory, ownership, rotation and removal from direct access paths. Check whether application and system accounts are onboarded to the bastion, whether their secrets are vaulted, and whether any service still connects directly to the CDE without passing through the gateway.

Rolling out PAM for a PCI DSS assessment

This sequence moves administrator, vendor and engineer access into a scoped bastion with MFA and recorded sessions, and ends with the evidence a QSA or the payment brands will sample for the Attestation of Compliance. Confirm the assessment type before anything is built, because the scope decision drives every later step.

Confirm scope and assessment type
Your team agrees with the QSA, or with the payment brand if you complete a Self-Assessment Questionnaire, which assessment type applies and which systems sit inside the cardholder data environment. Ask the assessor directly whether the bastion, its identity source and its recording store will be treated as in scope, since that decision changes the design. The step closes with a written scope statement that names the in-scope systems, the account types and the assessment template you will complete.
Inventory CDE access paths and accounts
Your infrastructure and security staff list every route into the cardholder data environment: SSH and RDP to servers, database consoles, Kubernetes clusters, application and system accounts, vendor support paths and remote access from outside your network. For each path, record who uses it, which accounts and shared credentials exist, and whether MFA is applied today. The step closes when the inventory is reconciled against network diagrams and identity directory exports, and every gap is assigned an owner.
Install the platform in a scoped zone
Your platform or infrastructure team, with DeployOpen if it is engaged, selects the bastion (such as JumpServer or Teleport, subject to the edition limits your environment needs) and installs it in a network segment that is segmented from general corporate traffic and controlled as part of the CDE. The team confirms supported deployment options, hardens the host, restricts inbound and outbound paths and sets up backups for configuration and recordings. The step closes when a tested build passes a documented hardening checklist and the scope boundary is reflected in the network diagram.
Integrate identity provider and MFA
Your identity team connects the bastion to the workforce identity provider so each person signs in with a named account, and enforces MFA for every administrative and remote path into the CDE. Confirm with the QSA how phishing-resistant authenticators will be handled under the 8.4 sub-requirements, since the rules for passkeys and other phishing-resistant methods are specific. The step closes when test sign-ins prove that no CDE path can be reached with a local or shared account and that MFA is required on each one.
Migrate admin and vendor access
Your administrators and third-party support teams move from direct logins, shared SSH keys and standing VPN accounts to bastion-brokered access, with individual roles granted on a least-privilege basis and vendor accounts limited to the systems and time window they need. Remove or disable legacy paths once the bastion route is proven, and document each approval rule. The step closes when the legacy access list is empty, every privileged role has a documented business justification and approver, and vendor sessions are tied to tickets or named engagements.
Enable session recording and SIEM export
Your security operations team turns on session recording for all privileged sessions into the CDE and forwards bastion logs, including login events, authorization decisions and session metadata, to the SIEM. Confirm the recording retention period with the QSA and your payment brand instead of assuming a value, and confirm that recordings are protected from modification and that access to them is itself logged. The step closes when a test session is recorded, searchable in the SIEM, and retained in the location your assessor will examine.
Run the first access review
Your managers and system owners review every account and privilege that can reach the CDE, including vendor and third-party accounts, and confirm whether each one is still needed and correctly scoped. Inappropriate access is removed, and management formally acknowledges the results. Agree the review cadence with your QSA, keeping in mind the six-month minimum for user accounts and the risk-analysis basis for application and system accounts. The step closes with a signed review record and a list of corrective actions with owners.
Collect evidence for the AOC
Your compliance lead assembles the artifacts the assessor will sample: scope documents, network diagrams, the access inventory, configuration exports, MFA test results, recorded-session samples, SIEM log examples, access review records and change history. Map each artifact to the requirement it supports, then hand the package to the QSA or complete the SAQ with your payment brand. The step closes when the assessor confirms the evidence set is sufficient, and the Attestation of Compliance is issued by the qualified assessor or your self-assessment is submitted. DeployOpen prepares evidence but does not issue the attestation.

PCI DSS PAM questions buyers ask before hiring help

What drives the cost of a PCI DSS PAM project on open source?

The cost is driven by the number of systems behind the bastion, the platform edition you need, how much identity integration is required, how much session recording you must keep, and how much scoping work the CDE boundary needs. Platform licenses are only one line. Implementation labor is paid for by the scope agreed in writing, and recurring costs come from storage, hosting, patching and administration. JumpServer's Community edition is free for up to 5,000 assets in a standalone topology, according to its pricing page, but Enterprise features such as ticket and just-in-time approval workflows, Oracle and SQL Server access and SSO sit in paid tiers, so check which features your design requires before you assume the free edition fits. Ask for a quote that separates one-time design and rollout work from recurring support and storage.

Which PAM costs are one-time and which recur each year?

One-time costs usually include requirements and scoping, architecture, installation, integration with the identity provider, migration of access paths, and the evidence pack for the first assessment. Recurring costs include platform support or subscriptions if you buy an Enterprise edition, hosting and backup, growing session recording storage, periodic access reviews that PCI DSS 7.2.4 requires at least every six months, and patching of the bastion itself. Teleport prices by active users and protected resources, and its pricing page does not publish figures, so ask any vendor to state how the unit is counted for your environment. Request both a one-time and an annual view in every quote.

How long does a PCI DSS bastion rollout take?

Rollout time depends on how many systems and access paths sit inside the cardholder data environment, how many of them already have local accounts or shared credentials, how many identity sources must connect, and how quickly the owners of each system can test and approve changes. Systems with clear owners and standard protocols such as SSH and RDP move faster than legacy databases or vendor-managed appliances. No duration can be stated without an inventory, so ask the implementation partner for a schedule based on your asset list and a phased plan that moves the highest-risk CDE access first.

Can our internal team run a PCI DSS PAM project alone?

Some teams can, especially if they already operate Linux, identity and network services and have someone who knows PCI DSS scoping. The work usually stalls on three things: defining the CDE boundary and the bastion's own scope, writing the access review and approval procedures that the assessor will sample, and finding time for testing across many systems. An internal team that owns those items can build the platform alone. If it does not, a fixed-scope engagement can cover the design, deployment, hardening, integrations and evidence preparation, while your staff keep ownership of policy and sign-off. Confirm with your QSA which artifacts they expect to see before you decide.

What do we need to provide for a PAM implementation?

You need to provide a current inventory of systems in and around the cardholder data environment, a named owner for each system and each privileged group, the identity sources and MFA methods in use, and the network paths that reach the CDE from inside and outside your network. You also need access to your QSA or internal assessor early, so the design matches what they will test, and a decision-maker who can approve changes to production access. Ask your implementation partner to list these inputs in the written scope so gaps are visible before work begins.

Do passkeys satisfy PCI DSS requirement 8.4.2 for CDE access?

PCI SSC FAQ 1595 says FIDO2-compliant synced passkeys can qualify under requirement 8.4.2, which is the MFA requirement for all access into the CDE, when the account uses only phishing-resistant authentication. The note added in PCI DSS v4.0.1 applies to 8.4.2 only. PCI SSC FAQ 1596 states that phishing-resistant authentication alone does not satisfy 8.4.1 for non-console administrative access or 8.4.3 for remote access from outside your network, so administrators and vendors may still need a second factor. Confirm the exact passkey type, the platform and the account categories with your QSA before you rely on passkeys for any group.

Does DeployOpen issue the PCI DSS Attestation of Compliance?

No. DeployOpen plans, implements, hardens and documents the self-hosted PAM platform, and prepares the systems, controls and evidence that an assessment will examine. The Report on Compliance and the Attestation of Compliance are issued by a Qualified Security Assessor or through the SAQ process, and the payment brands decide which entities must validate. Ask your assessor which evidence formats they accept, such as session logs, approval records and access review sign-offs, and plan the implementation around those formats.

Standards and primary sources to check

Before you design the bastion or write its evidence plan, check the requirement text against the primary source yourself. The official PCI SSC Self-Assessment Questionnaire D for Service Providers is the template that most service providers and many larger merchants will complete, and its wording for requirements 7.2, 8.4 and 10 is what an assessor will hold your answers against. Use the PCI DSS v4.0 SAQ D for Service Providers as the reference for which sub-requirements apply to your entity type, and confirm with your acquirer or the relevant payment brand which self-assessment or report on compliance applies to you. The template is also where you will see which controls are expected to be evidenced, so read it before you choose a platform, not after the bastion is built.

Confirm that you are working from the active version. The PCI SSC announcement of PCI DSS v4.0.1 explains that v4.0.1 was a limited revision with no added or deleted requirements and that it is the only active version. Two FAQs settle the questions that matter most for a bastion design. FAQ 1595 addresses whether FIDO2-compliant synced passkeys satisfy the MFA rule for access into the CDE, and FAQ 1596 states that phishing-resistant authentication alone does not satisfy 8.4.1 or 8.4.3. Record the answers you rely on, with dates, because the standard is under review and any written interpretation should be kept in your assessment file. Also check whether your team's question about validation is answered by PCI SSC FAQ 1220, which makes clear that a certificate is not a validation of compliance and that a QSA report or an approved self-assessment with an Attestation of Compliance is what counts.

If the bastion cannot meet a requirement in its standard form, the decision is whether to use a compensating control or the customized approach. The PCI SSC explanation of compensating controls versus the customized approach describes the difference, and it should be read with your assessor early. Document the objective, the risk analysis and the evidence before rollout, not at assessment time. A realistic first decision is whether the recording and approval design will be presented under the defined approach, which needs no extra analysis, or whether a customized design is justified for a specific system. Ask your assessor which path they will accept for each system, and keep that answer with the access design.

How DeployOpen scopes and delivers PCI DSS PAM

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For PCI DSS privileged access, we start by defining the cardholder data environment boundary and the bastion's place within it, then build and document the access controls that requirements 7, 8.4 and 10 will be assessed against.

How we scope

Map every administrator, vendor and engineer path into the cardholder data environment before selecting a platform.
Define whether the bastion itself falls inside CDE scope, and record that decision in the written scope.
Agree in writing which systems, protocols, identity sources and session retention periods the engagement covers.

How we build

Deploy the chosen bastion in your infrastructure with MFA enforced for all CDE access paths, including vendor sessions.
Configure role-based permissions, approval workflows and session recording that match your documented least-privilege model.
Test access controls and session logging, including attempts to bypass the bastion, and record the results for your assessor.

How we hand over

Deliver configuration baselines, access matrices, runbooks and the evidence set that your QSA or internal team will sample.
Document the MFA method used for each access type, including any phishing-resistant authentication design you rely on.
Walk your operations and security staff through daily administration, access reviews and session log review procedures.

How we support

Offer ongoing support, upgrades and continuous testing as retainers after handover, scoped in writing.
Review access lists and session records on a cadence agreed with your team to support the 7.2.4 review cycle.
Coordinate with your independent assessor and the platform vendor when edition limits or upgrades affect your evidence.