Topic starter
06/09/2026 9:33 am
TL;DR: Application security fails when protections are designed for the wrong attacker, not when the cryptography itself is weak, according to Arxan Technologies. The IEEE 1735 example and the LinkedIn recruiting email both show that assumptions about environment, access, and automation now matter more than nominal compliance.
Editorial analysis by NHI Mgmt Group, based on content published by Arxan Technologies: “How to Meet (and Exceed!) IEEE 1735”.
Key questions
Q: How do security teams know when a control is built for the wrong attacker model?
A: A control is mismatched when it protects against a weaker or different attacker than the one the system actually faces.
Q: Why do technically sound controls still fail in real deployments?
A: Because technical soundness only proves the mechanism works under the assumptions in the design.
Q: What breaks when runtime integrity is not part of the design?
A: Static protections can be bypassed or observed if the attacker can instrument the running application.
Practitioner guidance
- Define the attacker capability set before selecting controls Document whether the control assumes a passive reader, trusted runtime, human-paced interaction, or limited query budget.
- Test protections against hostile runtime conditions Validate whether the application still resists abuse when the execution environment is under attacker influence, including crafted inputs, error handling, and instrumentation attempts.
- Reassess trust signals used in human-facing workflows Review whether names, titles, sender reputation, and profile data are being used as implicit trust controls in email, onboarding, or outreach flows.
Bottom line: The article’s central point is that security failures usually begin with a wrong attacker model, not a broken algorithm.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
06/09/2026 9:34 am
Threat model mismatch is the control failure, not cryptographic weakness: the article is right to shift the conversation away from whether a standard uses strong algorithms and toward whether it models the real attacker. If the system assumes a passive reader, a trusted client, or human-paced abuse, it is already behind the adversary. Practitioners should evaluate protections against attacker capability, not only algorithm choice.
A question worth separating out:
Q: Should teams treat AI-assisted social engineering as a security design issue?
A: Yes. AI-assisted social engineering changes the scale, consistency, and personalisation of deception, so systems that rely on human trust cues need stronger verification and reduced reliance on implicit legitimacy signals. The right response is to harden identity and trust checks, not to assume people will spot the fake.
👉 Read our full editorial: Threat model mismatch is the real failure in application security