Cryptographic Controls

VDA ISA 6.3.1 requires you to deploy cryptographic controls that protect confidential information both at rest and in transit, with disciplined key and certificate lifecycle management. To operationalize it fast, define what “confidential” means in your environment, map where that data is stored/transmitted, enforce approved encryption and protocols, and prove it with configurations, inventories, and key-management evidence ¹.

Key takeaways:

• Scope comes first: you must know which data is “confidential” and where it flows before encryption control decisions hold up in an assessment ¹.
• Assessors expect more than “we use TLS”: they look for algorithm standards, key management procedures, and certificate lifecycle controls ¹.
• Evidence wins: inventories, configurations, and operational records (rotation, revocation, exceptions) are what make cryptographic controls auditable ¹.

“Cryptographic controls requirement” questions usually stall on two points: ambiguity about which information is actually in scope, and operational gaps around keys and certificates. VDA ISA 6.3.1 is short, but it implies a complete, testable control system: encryption during storage and transmission, plus the management processes that keep cryptography trustworthy over time ¹.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat crypto like an enforceable standard, not a series of ad hoc engineering choices. That means (1) a clear policy position on approved algorithms/protocols, (2) a defensible key management model (ownership, storage, access, rotation, recovery, revocation), and (3) certificate lifecycle operations that prevent quiet drift into expired or weak configurations.

This page gives you requirement-level implementation guidance you can hand to Security Engineering, IT Ops, and Product teams. It also focuses on what assessors typically probe: coverage, correctness, and evidence. You will leave with a concrete step sequence, an evidence checklist, and an execution plan you can run as a small program.

Regulatory text

Requirement (excerpt): “Deploy appropriate cryptographic controls for protecting confidential information during storage and transmission.” ¹

Operator interpretation: You must implement encryption (or equivalent cryptographic protection) wherever confidential information is stored or transmitted, and you must operate the cryptography safely over time through algorithm selection, key management procedures, and certificate lifecycle management aligned with industry standards ¹.

What “appropriate” means in practice under assessment:

• You can explain why the chosen cryptography fits the data classification and threat model.
• Crypto is consistently deployed (not just “available”).
• Keys and certificates are controlled like high-impact security assets, with ownership, access control, change control, and lifecycle evidence.

Plain-English requirement: what this control is really asking for

1. Encrypt confidential data at rest across the platforms where it lives (endpoints, servers, databases, object storage, backups, removable media, and managed SaaS storage where you control configuration).
2. Encrypt confidential data in transit across internal and external networks, including service-to-service and admin access paths.
3. Run cryptography as a managed process: approved algorithms/protocols, centralized standards, key custody, rotation/revocation, and certificate issuance/renewal/expiry monitoring ¹.

Who it applies to

Entity types: Automotive suppliers and OEMs operating under TISAX expectations ¹.

Operational contexts that commonly fall in scope:

• Engineering data exchange (design files, CAD, requirements, test results).
• Production and quality systems that store customer confidential data.
• Corporate collaboration platforms and file shares used for customer projects.
• Data interfaces with third parties (logistics providers, testing labs, cloud providers, managed service providers).
• Remote access paths for admins, developers, and support.

If you share confidential information with a third party, crypto expectations extend to the handoff: secure transfer methods, strong authentication, and controls that prevent downgrade to weak protocols.

What you actually need to do (step-by-step)

Step 1: Define “confidential information” and scope the data flows

• Confirm your data classification rules and map which classes qualify as “confidential” for this requirement.
• Build a data flow inventory: where confidential data is created, stored, processed, transmitted, and archived.
• Identify “crypto control points”: databases, storage buckets, file shares, endpoints, integration APIs, message queues, SFTP gateways, VPNs, email, and collaboration tools.

Output: a scoped list of systems and flows that must meet encryption-at-rest and encryption-in-transit standards.

Step 2: Set enforceable cryptographic standards (not preferences)

Create a cryptographic standard that includes:

• Approved encryption for data at rest (platform-dependent).
• Approved protocols/ciphers for data in transit.
• Rules for cryptographic exceptions (who can approve, expiry of the exception, compensating controls).
• A minimum bar for key lengths/algorithms appropriate to your environment, aligned with industry standards ¹.

Keep it assessable: “must” statements, versioned document, owner, and review cadence.

Step 3: Implement encryption at rest with clear ownership

Typical implementation patterns that assess well:

• Managed storage encryption enabled by default (cloud disk encryption, database TDE, object storage SSE where applicable).
• Application-layer encryption for highly sensitive fields or when platform encryption is insufficient.
• Backup encryption (backups are often missed in assessments).
• Endpoint encryption for laptops and removable media that store confidential information.

Operationalize with:

• A control owner per platform (DBA lead, cloud platform team, endpoint team).
• A configuration baseline (golden settings) and drift detection.
• A remediation process for noncompliant assets.

Step 4: Implement encryption in transit end-to-end (internal and external)

Cover these paths explicitly:

• Browser/user access to apps.
• API/service-to-service traffic.
• Admin protocols (SSH, RDP gateways, bastion hosts).
• File transfers to customers and third parties.

Actions:

• Standardize on modern TLS configurations supported by your environment.
• Disable weak protocols and ciphers via baseline configs.
• Require secure channels for file exchange (avoid “email attachments” as a default for confidential data unless you can enforce cryptographic protection).

Step 5: Stand up key management procedures that match your risk

Assessors will look for the “how” of key security ¹. Your procedures should cover:

• Key generation: approved methods; segregation of duties for high-impact keys.
• Key storage: KMS/HSM where feasible; avoid hard-coded keys in code or CI variables without controls.
• Access control: least privilege; break-glass access with logging and approvals.
• Rotation and revocation: defined triggers (staff departure, suspected compromise, certificate expiry, system decommission).
• Recovery/escrow: where required, documented and controlled to prevent misuse.
• Logging: key access and administrative actions centrally logged.

A practical scoping rule: prioritize keys protecting broad data sets (KMS master keys, database TDE keys, TLS private keys) before narrow, local secrets.

Step 6: Operate certificate lifecycle management like a production process

This is the silent failure mode: expired certs, unmanaged ACME automation, unknown internal CAs, and orphaned private keys.

Minimum lifecycle controls ¹:

• Certificate inventory (public-facing and internal).
• Ownership and renewal method per certificate.
• Monitoring for impending expiry and failed renewals.
• Revocation/rotation process if private key compromise is suspected.
• Rules for private key storage and export restrictions.

Step 7: Validate with testing, monitoring, and exceptions management

• Run periodic scans/checks for encryption posture (at rest and in transit).
• Confirm that “encryption enabled” is actually “encryption in use” (for example, databases with TDE enabled but unencrypted backups).
• Track exceptions with expiry dates and remediation plans.
• Document residual risk decisions in a way a TISAX assessor can follow.

Step 8: Make it third-party ready

Where confidential data goes to a third party:

• Require encrypted transfer mechanisms and document them.
• Confirm the third party’s handling of keys/certificates when they host or process your confidential information.
• Ensure contracts and security schedules reflect cryptographic expectations. Keep the focus on operational controls and evidence, not marketing claims.

Operational note: If you manage many third parties, a system like Daydream can help you standardize crypto due diligence evidence requests (encryption at rest/in transit, KMS/HSM use, certificate management practices) and track exceptions so they do not sprawl across the supply chain.

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Governance and standards

• Cryptographic policy/standard with version history and approval.
• Data classification policy and mapping of “confidential” to systems/flows.
• Exception register for crypto deviations with approvals and remediation dates.

Technical proof (samples are fine if scoped)

• Screenshots/exports of cloud KMS settings, key policies, and audit logs.
• Database/storage encryption configuration evidence (TDE enabled, storage encryption enabled).
• TLS configuration baselines (load balancers, gateways, API front doors).
• Certificate inventory export and renewal/expiry monitoring evidence.

Operational records

• Key rotation records or change tickets.
• Certificate issuance/renewal logs (internal CA or external provider records).
• Incident/change records showing response to suspected key compromise or cert issues.
• Access reviews for privileged roles that can manage keys/certificates.

Common exam/audit questions and hangups

Assessors and auditors commonly probe:

• “Show me your inventory of where confidential information is stored and transmitted.”
• “Where is encryption enforced, and where is it only optional?”
• “How do you prevent weak TLS configurations from reappearing after deployments?”
• “Who can access KMS/HSM administrative functions, and how is that reviewed?”
• “How do you know certificates won’t expire unnoticed?”
• “Do backups and exports remain encrypted outside the primary system?”

Hangups that slow assessments:

• No unified certificate inventory.
• Encryption claims that do not cover backups, logs, or replicated environments.
• Exceptions with no expiry, no compensating controls, and no owner.

Frequent implementation mistakes (and how to avoid them)

1. Treating encryption as a project, not an operating process.
   Fix: assign owners for keys and certs, set runbooks, and keep operational logs ¹.

2. Ignoring “shadow” data stores.
   Fix: include exports, spreadsheets, email attachments, collaboration workspaces, and local dev/test copies in your data flow mapping.

3. Hard-coded keys and unmanaged secrets sprawl.
   Fix: require approved secret storage patterns and review CI/CD pipelines for secret handling.

4. Certificates managed per team with no central visibility.
   Fix: central inventory plus expiry monitoring, with clear ownership per certificate.

5. Over-reliance on third-party attestations.
   Fix: collect config-level evidence where you control settings, and ask third parties targeted questions about encryption scope, key custody, and certificate operations.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so treat the driver as assessment risk and customer trust expectations under TISAX programs ¹. Operationally, weak cryptographic controls translate into:

• Higher probability of confidential data exposure during transfer, remote access, or third-party collaboration.
• Larger blast radius if keys are compromised or certificates are mismanaged.
• Availability incidents from certificate expiry, which can become security incidents if teams apply unsafe emergency workarounds.

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Confirm classification: define which data is “confidential” for TISAX scope.
• Produce a scoped system and data flow list for confidential information.
• Publish a cryptographic standard and exception process (even if initial).
• Build a certificate inventory starter list (public endpoints first, then internal).

Next 60 days (Control rollout + evidence hardening)

• Enforce encryption-at-rest baselines on priority platforms (databases, object storage, endpoints, backups).
• Enforce encryption-in-transit baselines on priority paths (external ingress, remote admin, key APIs).
• Implement key management procedures: access control, logging, and rotation triggers.
• Stand up certificate expiry monitoring and ownership assignments.

Next 90 days (Assurance + third-party alignment)

• Validate coverage with scans/checks; document gaps and approved exceptions.
• Run tabletop exercises for key compromise and certificate revocation/rotation.
• Extend requirements to third-party transfer paths and hosted processing.
• Package assessor-ready evidence: inventories, baselines, logs, exceptions, and sample configs.

Frequently Asked Questions

Does “cryptographic controls” mean everything must be encrypted everywhere?

It means confidential information must be protected during storage and transmission, with choices justified as “appropriate” and operated safely through key and certificate management ¹. You can allow exceptions, but they must be controlled, documented, and risk-accepted.

Is TLS alone sufficient to meet encryption-in-transit expectations?

TLS is often the primary control for transit, but assessors will also look at configuration quality, downgrade resistance, and certificate lifecycle operations ¹. You must prove it is enforced and monitored, not just “supported.”

What evidence is most persuasive in a TISAX assessment?

A current inventory of in-scope systems/flows plus configuration proof for encryption at rest and in transit. Add operational records for keys and certificates (rotation, access control, expiry monitoring, exception handling) ¹.

How do we handle encryption when a third party hosts our confidential data?

Make encryption scope and key custody explicit in due diligence and contracts, then collect evidence that the third party actually operates encryption and key/certificate lifecycle controls. If your teams configure the service, keep your own configuration exports as evidence.

We have legacy systems that cannot support modern encryption. What do we do?

Put them into a time-bound exception process with a named owner, compensating controls, and a migration plan. Assessors generally accept legacy realities when you can show governance and progress.

Who should own certificate management: security or engineering?

Assign accountability centrally (often Security/Platform), but keep operational ownership with the team that runs the endpoint. The key is a single inventory, consistent standards, and monitoring that catches expiry and misconfiguration ¹.

Footnotes

1. VDA ISA Catalog v6.0