When CISA disclosed vulnerabilities in Johnson Controls Inc. Airwall versions ≤4.0.4, including CVE-2026-64887, a hard-coded cryptographic key flaw scoring 6.8 on CVSS, it raised a key question for internal audit teams: Is key management a controls issue you should test, or an engineering problem you should leave to IT?
This matters because hard-coded keys represent a vulnerability that's invisible in configuration reviews, persistent across deployments, and exploitable at scale once discovered. For internal auditors, the question isn't whether this is a problem. It's whether it's your problem.
Understanding the Issue
Hard-coded cryptographic keys are credentials embedded directly into application code or binaries. They're identical across every installation, meaning a single disclosure can grant attackers access to all deployments. The Airwall vulnerability shows the risk: an attacker with access to application files can decrypt sensitive data, bypass authentication, and read arbitrary files (CVE-2026-34492, CVSS 6.4).
Should internal audit teams take ownership of detecting and addressing these flaws? Or should cryptographic hygiene be a development and operations responsibility, with your role limited to verifying secure coding standards?
The Case for Audit Ownership
Auditors advocating for direct involvement in key hygiene make three points.
First, development teams might not fully grasp the control implications of their code. Hard-coded keys can seem like shortcuts, not control failures. If you don't test for them, they might go unnoticed. Your secure coding policy might prohibit hard-coded credentials, but unless someone verifies this in production binaries, it's just documentation.
Second, this is a detective control gap that internal audit can fill. Vulnerability scanners flag known CVEs, but they don't systematically audit code repositories or compiled applications for embedded secrets. Static application security testing (SAST) tools can identify hard-coded keys during development, but only if configured correctly and their findings are acted on. Internal audit can verify that SAST tools are deployed, findings are triaged, and critical-severity items are resolved before release.
Third, the consequences of failure are significant. Hard-coded keys undermine authentication controls (relevant to SOC 2 CC6.1, ISO 27001 A.9.4.2), create data exposure risks (GDPR Article 32, CCPA §1798.150), and in critical infrastructure contexts like Airwall's deployment, they threaten operational technology environments. These are material control deficiencies, not minor code quality issues.
Auditors in this camp recommend integrating key hygiene into your control testing program. Test for hard-coded credentials during SOC 2 or ISO 27001 audits. Require development teams to run SAST scans and provide evidence that cryptographic key findings are resolved. Review secrets management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) to confirm keys are externalized and rotated. Treat embedded keys like default passwords: as a control failure needing remediation and root cause analysis.
The Case for Leaving It to Engineering
Some auditors argue that owning key hygiene crosses the line from assurance into operations.
First, you might lack the tools or expertise. Identifying hard-coded keys requires source code access, binary analysis tools, and familiarity with cryptographic libraries across multiple languages. Most internal audit teams lack the technical depth to do this work competently. Missing embedded keys creates false assurance; flagging false positives wastes engineering time and damages credibility.
Second, this work duplicates what security engineering should already own. Application security teams run SAST and dynamic application security testing (DAST) in CI/CD pipelines. DevSecOps practices embed security checks before code reaches production. If you insert internal audit into this process, you're either redundant or a bottleneck. Your role should be to verify these practices exist and function, not to perform the scans yourself.
Third, the governance model matters. Internal audit's value comes from independence. If you're testing code for hard-coded keys, you're acting as a technical control, not an independent assurance function. When the next audit cycle arrives, who audits your key detection work? This creates a conflict that's hard to resolve without external auditors, adding cost without proportional value.
Auditors in this camp recommend a lighter-touch approach. Verify that secure software development practices include cryptographic key management requirements. Confirm that SAST tools are deployed and that high-severity findings have defined remediation SLAs. Review vulnerability management processes to ensure disclosed CVEs like the Airwall issues are triaged and patched promptly. Test that secrets management platforms are used for production credentials. But don't own the detection work itself.
Where Practitioners Actually Land
Most internal audit teams find a middle ground, usually based on risk.
For critical infrastructure systems, financial applications, or environments under strict regulatory oversight (NERC CIP, PCI DSS, HIPAA), auditors tend to be more hands-on. Audit programs may require evidence of SAST scan results, remediation timelines for cryptographic findings, and periodic reviews of secrets management configurations. The stakes are high enough that independence concerns take a back seat to assurance depth.
For lower-risk applications or environments with mature DevSecOps practices, auditors lean toward the verification model. You're testing that controls exist, not performing the controls yourself. You review security engineering's quarterly metrics on SAST findings, confirm that key rotation policies are documented and enforced, and escalate gaps to the audit committee. But you're not running static analysis tools or decompiling binaries.
Resource availability is another factor. If your organization has a dedicated application security team, internal audit can stay in an oversight role. If application security is under-resourced or nonexistent, internal audit often steps in by necessity, even if it's not the ideal governance structure.
Our Take
Internal audit should ensure cryptographic key hygiene controls exist and function, but you shouldn't own the detection work itself except in high-risk scenarios.
Here's why: the Airwall vulnerabilities weren't discovered by internal audit teams. They were disclosed by Johnson Controls to CISA through coordinated vulnerability disclosure. The control failure happened during development, and the detective control that should have caught it, secure code review and SAST, either didn't run or didn't escalate findings effectively. Internal audit's role is to verify that this pipeline exists and that it's effective, not to become part of the pipeline.
Test whether your organization uses SAST tools and whether cryptographic key findings are remediated within defined SLAs. Verify that secrets management platforms are deployed for production credentials and that key rotation occurs on schedule. Confirm that vulnerability management processes include a pathway for handling disclosed CVEs like CVE-2026-64887. These are audit activities that maintain your independence while providing meaningful assurance.
If you discover these controls don't exist, if there's no SAST in the CI/CD pipeline, no secrets management platform, no process for handling hard-coded key findings, escalate it as a significant deficiency. At that point, you're not overstepping; you're doing exactly what internal audit should do: identifying control gaps that management must address.
But resist the temptation to fill the gap yourself by running static analysis tools or performing code reviews. That's a short-term fix that creates a long-term governance problem. Push for the right control structure instead.
