[{"content":"Most conversations about quantum computing and security follow a predictable arc: someone mentions Shor\u0026rsquo;s algorithm, everyone agrees RSA will eventually break, and the room collectively shrugs because \u0026ldquo;real quantum computers are decades away.\u0026rdquo;\nThat framing is dangerously wrong. Not because large-scale fault-tolerant quantum computers are imminent — they aren\u0026rsquo;t — but because the threat model doesn\u0026rsquo;t require them to be.\nHarvest Now, Decrypt Later Nation-state actors are already collecting encrypted traffic at scale. The bet is simple: capture today\u0026rsquo;s ciphertext, store it cheaply, and decrypt it when quantum hardware catches up. If your data has a shelf life longer than 10–15 years — and most sensitive enterprise, government, and financial data does — you have a quantum security problem right now.\nThis isn\u0026rsquo;t speculation. Intelligence agencies have publicly acknowledged the strategy. The question isn\u0026rsquo;t whether it\u0026rsquo;s happening; it\u0026rsquo;s whether your organization\u0026rsquo;s data is worth storing.\nWhat Actually Breaks After five years at IonQ working alongside quantum physicists and building security assessment toolkits, I can be more specific than most about what\u0026rsquo;s at risk:\nRSA and ECDSA keys are the primary targets. Shor\u0026rsquo;s algorithm factors large integers and computes discrete logarithms efficiently on a quantum computer. Every RSA key, every ECDSA signature, every DH key exchange in your infrastructure is theoretically vulnerable. That includes your TLS certificates, SSH keys, code signing certificates, and blockchain wallets.\nAES is bruised, not broken. Grover\u0026rsquo;s algorithm provides a quadratic speedup for brute-force search, which effectively halves your symmetric key strength. AES-256 becomes AES-128 equivalent. That\u0026rsquo;s still strong — but AES-128 becomes AES-64 equivalent, which is not.\nThe timeline varies by algorithm and key size. A 2048-bit RSA key requires roughly 4,000 logical qubits to break. We\u0026rsquo;re currently at dozens of reliable logical qubits, not thousands. But the trajectory is non-linear, and \u0026ldquo;15 years away\u0026rdquo; is within the threat window for harvest-now attacks.\nWhat to Do About It NIST finalized its post-quantum cryptography standards in 2024 — ML-KEM (Kyber) for key encapsulation, ML-DSA (Dilithium) and SLH-DSA (SPHINCS+) for digital signatures. The standards exist. The migration path is defined. What most organizations lack is:\nA cryptographic inventory. You can\u0026rsquo;t migrate what you can\u0026rsquo;t find. Most enterprises have no idea where all their cryptographic dependencies live — embedded in libraries, baked into protocols, hardcoded in legacy systems.\nPrioritization based on actual risk. Not everything needs to migrate at once. The priority should be driven by data sensitivity, retention period, and exposure to harvest attacks — not by what\u0026rsquo;s easiest to change.\nMigration without disruption. PQC algorithms have different performance characteristics (larger key sizes, different handshake behaviors). Migration requires testing, not just configuration changes.\nThe Credibility Gap The Big Four consulting firms will sell you a quantum risk assessment. So will a dozen startups. The difference is that most of them are working from NIST publications and analyst reports. They can tell you that quantum computers will break RSA. They can\u0026rsquo;t tell you how — because they\u0026rsquo;ve never built or operated one.\nI spent five years inside a quantum computing company. I\u0026rsquo;ve built toolkits that dissect TLS handshakes, extract RSA moduli, and model Shor\u0026rsquo;s attack at the circuit level. I\u0026rsquo;ve worked with the physicists building the hardware. That context matters when you\u0026rsquo;re trying to separate genuine risk from marketing fear.\nIf your organization is starting to think about quantum security, I\u0026rsquo;d rather you think about it clearly than urgently. The sky isn\u0026rsquo;t falling today — but the window to prepare is shorter than most people assume.\nGet in touch if you want to talk through what quantum risk looks like for your specific infrastructure.\n","permalink":"http://kondasecurity.com/blog/quantum-threat-is-not-theoretical/","summary":"Most quantum security conversations stop at \u0026lsquo;someday.\u0026rsquo; After five years inside a quantum computing company, I can tell you exactly what\u0026rsquo;s vulnerable, when, and what to do about it.","title":"The Quantum Threat Is Not Theoretical"},{"content":"The security industry has a reliable pattern: a new technology emerges, vendors rebrand existing products around it, and CISOs are left trying to figure out what\u0026rsquo;s genuinely new versus what\u0026rsquo;s last year\u0026rsquo;s tool with a fresh coat of paint.\nAI security is in that phase right now. Let me try to cut through it.\nTwo Distinct Problems \u0026ldquo;AI security\u0026rdquo; conflates two very different challenges:\nSecuring AI systems — How do you protect applications that use LLMs, machine learning models, or AI agents from attack? This includes prompt injection, training data poisoning, model theft, data leakage through model outputs, and supply chain risks in model dependencies.\nUsing AI for security — How do you leverage AI to find vulnerabilities faster, triage incidents more effectively, or automate remediation? This is about augmenting your security team, not protecting AI.\nMost vendor pitches blur these together. They shouldn\u0026rsquo;t — the skill sets, tools, and threat models are different.\nWhat\u0026rsquo;s Genuinely New About Securing AI Some AI security risks are novel. Prompt injection is a real problem without a clean solution — it\u0026rsquo;s fundamentally different from SQL injection because the \u0026ldquo;query\u0026rdquo; and the \u0026ldquo;data\u0026rdquo; travel through the same channel (natural language). You can\u0026rsquo;t parameterize your way out of it.\nTraining data poisoning is concerning at scale but largely theoretical for most enterprises using commercial models. Model theft matters for organizations training proprietary models — less so for API consumers.\nThe risk I see most often in practice: data leakage through careless AI integration. Organizations connecting LLMs to internal data sources without thinking carefully about what the model can access and what it might include in responses. This isn\u0026rsquo;t an exotic AI attack — it\u0026rsquo;s a classic access control failure in a new context.\nWhat\u0026rsquo;s Just Application Security with a New Name A lot of \u0026ldquo;AI security\u0026rdquo; is standard application security applied to AI-powered applications:\nAPI authentication and authorization for model endpoints Input validation on user-facing prompts Rate limiting and abuse prevention Logging and monitoring of model interactions Dependency management for ML libraries These are important. They\u0026rsquo;re also not new. If your application security program is solid, you\u0026rsquo;re already halfway there. If it isn\u0026rsquo;t, an \u0026ldquo;AI security\u0026rdquo; product won\u0026rsquo;t fix the foundation.\nUsing AI for Security: What Actually Works I build security tools with Claude and Codex daily. Here\u0026rsquo;s what I\u0026rsquo;ve found genuinely useful:\nCode review augmentation. LLMs are surprisingly good at identifying security issues in code — not perfect, but they catch things that pattern-based scanners miss, especially logic flaws and business logic vulnerabilities. The key is using them as a collaborator, not a replacement for human review.\nVulnerability analysis and triage. When you\u0026rsquo;re staring at a list of 500 findings from a scanner, an LLM can help prioritize by understanding context — what the code actually does, whether a vulnerable function is reachable, whether the finding is a false positive.\nSecurity policy and documentation. Drafting policies, mapping controls to frameworks, generating risk assessments — LLMs accelerate the tedious parts of GRC work dramatically.\nWhat doesn\u0026rsquo;t work yet: Fully autonomous security testing. Despite the demos, LLMs can\u0026rsquo;t reliably replace a skilled penetration tester. They\u0026rsquo;re a force multiplier for competent practitioners, not a substitute for expertise.\nThe Practical Advice If you\u0026rsquo;re a CISO trying to figure out your AI security strategy:\nStart with your existing application security program. Most AI security risks are application security risks. Shore up the basics first.\nInventory your AI usage. Know where LLMs and AI tools are being used across your organization — both sanctioned and shadow IT. You can\u0026rsquo;t govern what you can\u0026rsquo;t see.\nFocus on data flows. The highest-risk scenarios involve AI systems with access to sensitive data. Map those flows and apply least-privilege principles.\nSkip the AI security platform buy. At this stage, you probably don\u0026rsquo;t need a dedicated AI security product. You need policies, training for your engineering teams, and integration of AI considerations into your existing security review processes.\nExperiment with AI for security. Give your security team access to LLMs and let them figure out where it helps. The ROI is in augmenting skilled practitioners, not replacing them.\nThe organizations that will get AI security right are the ones with strong security fundamentals and a willingness to learn the new threat landscape — not the ones that buy the flashiest new product.\nReach out if you\u0026rsquo;d like to discuss AI security strategy for your organization.\n","permalink":"http://kondasecurity.com/blog/ai-security-beyond-the-hype/","summary":"Everyone is selling AI security. Most of it is repackaged application security with a new label. Here\u0026rsquo;s what actually matters when securing AI systems — and using AI to secure yours.","title":"AI Security: Separating What's Real from What's Marketing"},{"content":"I\u0026rsquo;ve seen organizations with beautifully written security policies — hundreds of pages, mapped to NIST controls, approved by the board — that couldn\u0026rsquo;t stop a phishing email from becoming a breach. And I\u0026rsquo;ve seen scrappy teams with minimal documentation that instinctively make secure choices because their engineering culture rewards it.\nThe difference isn\u0026rsquo;t the policy. It\u0026rsquo;s the culture.\nWhy Policy Alone Fails Security policies tell people what they should do. Culture determines what they actually do when nobody\u0026rsquo;s watching and when the deadline is tomorrow.\nMost security policies are written for auditors, not for the people who need to follow them. They\u0026rsquo;re long, legalistic, and disconnected from daily work. Engineers read them once during onboarding — if they read them at all — and never open them again.\nThe policy says \u0026ldquo;all code must undergo security review before deployment.\u0026rdquo; What happens in practice? The security review queue is a bottleneck, the security team takes a week to respond, and engineers learn to route around it. Not because they don\u0026rsquo;t care about security, but because the process wasn\u0026rsquo;t designed with their workflow in mind.\nWhat Security Culture Actually Looks Like Organizations with strong security culture share a few traits:\nSecurity people earn technical credibility. Engineers follow security guidance from people they respect technically. If your security team can\u0026rsquo;t read code, can\u0026rsquo;t explain why a finding matters at the implementation level, and can\u0026rsquo;t propose realistic fixes — your guidance will be ignored, politely or otherwise.\nThis is the single biggest factor I\u0026rsquo;ve seen in 27 years. When I walked into engineering meetings at IonQ and could discuss their systems at the code level, the dynamic changed completely. Security stopped being \u0026ldquo;the team that says no\u0026rdquo; and became \u0026ldquo;the team that helps us ship safely.\u0026rdquo;\nSecurity is a collaboration, not a mandate. The agile values I brought from software development transformed how I run security programs. Favor working together over following contracts. Favor conversations over tickets. Favor enabling the right behavior over blocking the wrong behavior.\nRisk is communicated in business terms. \u0026ldquo;This is a critical vulnerability\u0026rdquo; means nothing to a product manager. \u0026ldquo;This vulnerability lets an attacker read any customer\u0026rsquo;s data, and we have 10,000 customers with PHI\u0026rdquo; gets a response. Security leaders who can translate between technical risk and business impact build trust with both engineering and executive teams.\nEngineers own security in their domain. The best security programs don\u0026rsquo;t have a central team gatekeeping every decision. They have security engineers embedded in product teams, security champions in every engineering group, and tooling that gives developers immediate feedback in their own workflow.\nHow to Build It If you\u0026rsquo;re a CISO or security leader trying to shift culture, here\u0026rsquo;s what I\u0026rsquo;ve found works:\nStart by being useful. Before you write a single policy, go help an engineering team fix a real security problem. Write a patch. Review their architecture. Show up as a contributor, not an auditor. Everything else builds on this foundation.\nMake the secure path the easy path. If doing the secure thing requires three extra steps and an approval process, people will skip it. Invest in tooling, automation, and process design that makes security the path of least resistance.\nShare context, not just directives. When you issue a security requirement, explain the threat model behind it. Engineers who understand why will make better judgment calls in situations your policy didn\u0026rsquo;t anticipate.\nCelebrate security wins publicly. When an engineer reports a vulnerability, catches a misconfiguration, or builds a security feature — recognize it. Culture is shaped by what gets rewarded.\nAccept imperfection. A security program that\u0026rsquo;s 80% effective and embraced by the organization will outperform a theoretically perfect program that everyone resents and circumvents.\nThe Builder\u0026rsquo;s Advantage I\u0026rsquo;m biased, but I believe the best security leaders are builders. Not because management skills don\u0026rsquo;t matter — they absolutely do — but because the ability to prototype solutions, write code alongside your teams, and demonstrate technical depth changes the power dynamic fundamentally.\nWhen your security team can show up to an architecture review and contribute meaningfully to the design — not just critique it — you earn a seat at the table that no title or policy can give you.\nSecurity culture starts with security leaders who lead by doing, not just by governing.\nLet\u0026rsquo;s talk about building a security culture that actually works at your organization.\n","permalink":"http://kondasecurity.com/blog/security-culture-eats-policy/","summary":"You can write perfect security policies and still have a terrible security posture. What actually changes behavior is culture — and culture comes from how security leaders show up.","title":"Security Culture Eats Policy for Breakfast"},{"content":"Matt Konda I\u0026rsquo;m a security leader and technical founder with 27+ years of experience building software, breaking it, and leading teams that do both.\nMost recently, I served as Head of Security at IonQ (2021–2026), a publicly traded quantum computing company, where I built the entire security program from the ground up. That meant everything — hiring a team of 12, achieving SOC 2, ISO 27001, CMMC, and PCI certification, managing security through six acquisitions, building a quantitative risk framework, and partnering with federal agencies on information sharing. Zero material breaches.\nBefore IonQ, I founded Jemurai, a security consulting firm I ran for 12+ years. We built a world-class penetration testing practice, delivered hundreds of engagements across quantum, finance, healthcare, and insurance industries, and created two SaaS platforms: SecurityProgram.io for security program management and JASP for cloud security assurance.\nI served as OWASP Global Board Chair (2016–2017), leading the 40,000+ member application security community through its maximum board terms. I\u0026rsquo;ve spoken at DefCon, OWASP AppSecUSA, LASCON, RailsConf, GotoCon, and many other conferences.\nI wrote Building a Security Program, a practitioner\u0026rsquo;s guide covering NIST standards, risk management, application security, incident response, and security automation.\nWhat I bring Technical depth + leadership. I write code daily — currently building AI-powered security tools with Claude and Codex for vulnerability discovery, code analysis, and automated remediation. I\u0026rsquo;m not evaluating vendor slide decks; I\u0026rsquo;m building the tools myself.\nBuilder\u0026rsquo;s mindset. Whether it\u0026rsquo;s a security program, a SaaS product, or a consulting practice, I\u0026rsquo;ve built things from zero and watched them mature. I know what it takes to go from \u0026ldquo;we have nothing\u0026rdquo; to \u0026ldquo;we passed the audit.\u0026rdquo;\nSecurity breadth. Application security, cloud security, network security, supply chain security, insider threat, physical security, GRC, incident response, penetration testing — I\u0026rsquo;ve done the work across all of these domains, not just managed teams doing them.\nBackground M.S. Computer Science — Rensselaer Polytechnic Institute B.A. Biology \u0026amp; History — Brown University 27+ years in software engineering and security Languages: Python, Go, Ruby, Java, JavaScript Cloud: AWS, GCP Frameworks: NIST 800-53, SOC 2, ISO 27001, CMMC, PCI DSS, FAIR Connect Email: matt@kondasecurity.com LinkedIn: linkedin.com/in/mattkonda GitHub: github.com/mkonda Speaking: speakerdeck.com/mkonda ","permalink":"http://kondasecurity.com/about/","summary":"Matt Konda — security leader, technical founder, hands-on practitioner.","title":"About"},{"content":"Every engagement is led by me directly. No junior staff, no handoffs, no bait-and-switch.\nExecutive Security Advisory For boards, executive teams, and CISOs navigating high-consequence security decisions.\nBoard Briefings — Clear, calibrated assessments of organizational security posture, emerging threats, and strategic risk. Designed for directors and executives who need signal, not jargon.\nCISO Advisory — Strategic counsel for security leaders on program direction, team structure, vendor evaluation, budget justification, and organizational positioning. Built on experience as a CISO, a founder, and an OWASP board chair — I understand the role from every angle.\nOrganizational Security Readiness — Assessment of whether your security function is structured, staffed, and positioned to handle what\u0026rsquo;s coming. Especially valuable during rapid growth, pre-IPO, or board-level scrutiny.\nAI Security Strategy AI is changing how software gets built and how it gets attacked. Most organizations are moving faster on adoption than on governance.\nAI Security Governance — Policies, risk frameworks, and controls for organizations deploying AI tools and building AI-powered products. Covers prompt injection, data leakage, model supply chain, and responsible use — grounded in what actually works, not theoretical frameworks.\nAI-Powered Security Tooling — I build custom security automation using LLMs (Claude, Codex) for vulnerability discovery, code analysis, and remediation. If you want to understand what AI can actually do for your security team, I can show you — with working tools, not slide decks.\nAI Application Security — Security architecture and assessment for AI-powered applications, covering the threat landscape that traditional AppSec reviews miss.\nQuantum / PQC Readiness Every enterprise CISO is asking what quantum computing means for their security posture. After five years inside a public quantum computing company, I give concrete answers — not theoretical hand-waving.\nQuantum Threat Assessments — End-to-end analysis of your cryptographic exposure. I dissect your protocols (TLS, SSH, blockchain), extract vulnerable cryptographic material, map quantum attack vectors (Shor\u0026rsquo;s, Grover\u0026rsquo;s), and deliver actionable reports with timelines and migration priorities.\nPost-Quantum Migration — Cryptographic inventory, PQC algorithm selection (ML-KEM, ML-DSA, SLH-DSA), migration roadmaps prioritized by \u0026ldquo;harvest now, decrypt later\u0026rdquo; risk, and validation testing of PQC implementations.\nPQC Readiness Assessments — Lightweight infrastructure scans to identify non-quantum-resistant cryptography and build a prioritized remediation plan.\nSecurity Program Build-Out Building security programs from scratch is what I\u0026rsquo;ve done my entire career — at IonQ, at Jemurai for dozens of clients, and at Trustwave for security products.\nFractional CISO / vCISO — Experienced security leadership without a full-time hire. I\u0026rsquo;ve delivered this model for years, including my initial engagement at IonQ, which started as a fractional CISO role before converting to full-time.\nZero-to-Audit Program Build — Framework selection (NIST 800-53, ISO 27001, SOC 2), policy development, control implementation, team hiring, vendor selection, and audit preparation. I\u0026rsquo;ve taken organizations from nothing to certified.\nM\u0026amp;A Security Due Diligence — I\u0026rsquo;ve managed security through six acquisitions at IonQ. Target company security assessments, risk identification, and integration planning.\nTechnical Due Diligence \u0026amp; Architecture Review For investors, acquirers, and executive teams who need a credible technical assessment before making decisions.\nAcquisition Due Diligence — Deep technical and security assessment of target company infrastructure, code, and practices. Not a checklist — a judgment call from someone who has been on both sides of M\u0026amp;A.\nArchitecture Review — Security-focused assessment of system design, cloud infrastructure, and software architecture. I read code and understand systems at the engineering level.\nCode Review — Security review of critical codebases. I\u0026rsquo;ve spent decades writing software in Python, Go, Ruby, Java, and JavaScript — my reviews reflect a practitioner\u0026rsquo;s understanding of what\u0026rsquo;s actually exploitable versus what\u0026rsquo;s theoretical.\nHow I Work Direct engagement. I do the work. Every deliverable has my name on it. Technical credibility. I write code, read code, and understand systems at the engineering level. Recommendations land because they come from someone technical teams respect. Actionable output. Clear, prioritized recommendations. Not 200-page reports that sit on a shelf. Flexible models. Advisory retainers, project-based engagements, or fractional leadership — structured to fit your needs. Start a conversation →\n","permalink":"http://kondasecurity.com/services/","summary":"Executive security advisory, AI security strategy, quantum readiness, and security program leadership.","title":"Advisory Services"},{"content":"For advisory retainers, board briefings, AI security strategy, quantum readiness assessments, and technical due diligence — reach out directly. I respond personally to every inquiry.\nEmail matt@kondasecurity.com\nLinkedIn linkedin.com/in/mattkonda\nLocation Based in Dallas, TX. Available for remote engagements nationwide and open to travel as needed.\nWhat to expect I typically respond within one business day. Initial conversations are exploratory — no commitment required. If there\u0026rsquo;s a fit, I\u0026rsquo;ll propose a scope and structure that matches what you need.\n","permalink":"http://kondasecurity.com/contact/","summary":"Start a conversation about advisory retainers, board briefings, AI security, quantum readiness, and due diligence.","title":"Contact"}]