Why Good Security Concepts Don't Always Work in Practice: The Problem with Enterprise and Shadow IT
DEF CON 34's open-source badge chip is a thoughtful example of transparent security design
But no matter how good the innovation, organizations must be able to integrate it into their stack. This means understanding how it improves workflows and impacts security.
This year's DEF CON badge’s Baochip has been designed to solve a decades-old hardware security problem: verifying that a manufactured chip matches its published design. Organizations no longer need to trust vendor claims on faith. The operating system, firmware, processor core, cryptographic engine, and I/O layer are all public and open to inspection
Researchers can unpack the silicon and compare it to the schematic. Over 30,000 attendees will take a badge home this year, each one a potential catalyst for better security practice. Whether that potential is realized depends on the organization, not the chip. Without the technical infrastructure, workforce, and security culture to support it, the chip's impact will be limited.
This is the implementation validity problem: value depends on more than a model's elegance, utility, or novelty. Realizing that value requires competent personnel, budget, a procurement path, and a non-redundant purpose for the device. Most of an organization's authentication security rests on these conditions (not on the ingenuity of the design).
Why implementation validity requires resources and context
Large organizations have their own momentum. Even when staff are competent and agile, infrastructure and technical constraints determine the speed of adoption. SMEs have the advantage of faster decision-making cycles, but they might not have the workforce, budget, or procurement structure to sustain it. Design and practice diverge here, and no amount of innovation closes that gap on its own. Addressing it requires treating model validity and implementation validity as two discrete variables (Table 1).
Table 1. Defining model and implementation validity
Model validity reflects the underlying design principles of software or hardware. It concerns whether a product does what it claims, which requires diverse sources of evidence rather than proof-of-concept demonstrations, including testing, comparisons to competitors, and principled metrics.
Research can provide evidence to support the validity of a model, but this does not address whether adoption is feasible. Formally, implementation validity assesses feasibility by examining the resources, infrastructure, and goals within an organization's context. CISOs must ask themselves whether the technology matches the needs of their organization and team. Otherwise, organizations risk rejecting innovation before it's fully realized, or shelving products without further evaluation.
Most hardware-backed MFA is introduced into an organization through procurement, which provides the resources needed for adoption. An employee returning from DEF CON with their own token does not have this. The employee might understand the token's operations and have the resources to sustain its use, but colleagues will not. When that employee leaves the organization, so do the token's benefits .
Resources are only part of the implementation validity problem. The role the technology fulfills must also be defined. A device with the necessary resources can still fail if it does not serve a specific, non-redundant function.
De-implementation of existing technology requires organizational change that can be costly in terms of retraining and learning curves. Most organizations already have an MFA solution with its own supply chain. A second, parallel authentication device does not necessarily add security. It creates shadow IT hat is invisible to the organization. That's often the appeal. But security is a holistic property of an organization, reflecting how its people and technology are integrated.
Why Innovations Fail
Innovations can fail even when the underlying design is sound. Recent stories about enterprise AI adoption show this clearly: rather than principled assessment, comparison, testing and integration, people are either accept or reject AI. A technology's success depends instead on its organizational environment, shaped by who champions it, how well it fits the existing stack, and how much it disrupts current workflows.
Assessing implementation once is insufficient, since organizational structures and technology stacks keep evolving. Implementation validity requires continuous evaluation of how a technology serves an organization's current and near-term needs. Consider the following four technologies in these terms (Table 2).
Table 2. Model and implementation validity
1. FIDO2/WebAuthn hardware security keys. Public-key challenge-response authentication has been formally analyzed and resists phishing and credential-replay attacks, even if imperfectly, giving FIDO2 strong model validity. Implementation validity is equally strong: the protocol is built into every major OS and browser, procurement channels are mature, and IT staff already have provisioning and revocation tooling through existing identity providers. FIDO2 has scaled inside larger organizations without shadow IT.
2. Signature-based antivirus/EDR. Signature matching catches known threats but generalizes poorly to novel or polymorphic malware. Zero-day detection rates are also relatively poor, a limitation well established in malware detection literature. Implementation validity is high regardless: the vendor market is mature, the software integrates into existing endpoint management systems, staff are already trained on it, and compliance frameworks often require it. Here, organizational readiness exceeds the model's validity.
3. Open-hardware security tokens (DEF CON 34 badge chip). The chip's design is mostly public and checkable against its schematic, giving it model validity. Implementation validity is low, since it has no budget line, no assigned staff, no complementary technology, and no defined role relative to the organization's existing MFA. It will remain shadow IT, like other tools employees bring into the workplace on their own, from LLMs to personal password managers.
4. User and Entity Behavioral Analysis (UEBA). Model validity is weak because ground truth for “anomalous” behavior is hard to establish, insider threat base rates are sufficiently low to produce high false positive rates, and behavioral baselines drift as work patterns change. This has been attributed to adopting a context-independent statistical average that cannot capture legitimate behavior variability, reducing the model validity of traditional UEBA.
Implementation validity is also limited. With most security teams identifying false positives as their main challenge, uninvestigated threats demonstrate the importance of evaluating implementation validity. To be effective, UEBA needs sustained data engineering over many log sources, dedicated analysts to triage output, and tuning that most SOCs are understaffed to provide, so alert fatigue sets in and the tool goes underused.
How to Evaluate Implementation Validity of an Innovation
Implementation validity is not a property of the technology itself. Designers can provide the most principled and tested technology without it impacting an organization’s workflows positively. It is instead a property of the organization's readiness to sustain it. A technology (or human) workflow offers value to the extent that the organization around it is ready to use it, not on whether it has worked for others or is the ‘industry standard’: You would not hire another CISO to run your phishing simulations.
Organizations must consider whether the financial, staffing, material, and structural conditions exist to support the technology over time, and whether it fills a role nothing else already does. Leadership needs to support that evaluation with budget, authority, and follow-through, rather than treating procurement as the end of the decision.
CISOs at a hiring panel at this year’s BSides echo the stories we hear elsewhere: the adoption decision rightly lies with their team. Teams will need to use the technology; they understand what the day-to-day workflow can absorb and what it cannot. They also need an evaluation framework.
The implementation validity framework in Table 3 identifies six sources of evidence an organization must check before and after adopting a security technology. Each is illustrated with two contrasting cases: enterprise MFA introduced through procurement, and technologies like the DEF CON badge token adopted by an individual employee.
Table 3. Sources of evidence for implementation validity, applied to hardware authentication tokens. Adapted from Schoenherr and Hamstra.
Technologies earn their value based on their unique role, whether their features match what a specific organization can support, and whether their role in the stack is one nothing else already fills. Left unaddressed, a technology not positioned in workflows remains idle or becomes an invisible scaffold, propping up workflows no one has reviewed, creating unknown vulnerabilities. We cannot assume that technologies serve an organization’s interest or maintain security without proof.
Organizational leaders must adopt formal evaluation frameworks that contextualize innovations, providing the evidence for model capabilities, return on investment, and integration within their current stack and organizational processes. Failure to do so can increase your organization’s human and technical attack surface.
What is feature engineering
In practice, feature engineering is both science and a bit of witchcraft. It often involves both iteration and experimentation to uncover hidden patterns and relationships within the data. For instance, a data scientist might transform raw sales data into features such as average purchase value, purchase frequency, or customer lifetime value, which can significantly boost the performance of a churn prediction model. By thoughtfully engineering features, practitioners can provide machine learning models with the most informative inputs, ultimately leading to better accuracy and more robust predictions.
What’s more?
- Incorporate more and more data sources
- Feature engineering platform
What is data engineering
As we mentioned above, feature engineering is certainly a subset of data engineering. It involves the ingestion of data from a source, applying a series of transformations, and making the final result available to be queried by a model for training purposes. You can construct feature engineering pipelines to resemble data engineering pipelines, having schedules, specific source and sink destinations, and availability for querying. However, this configuration would only really apply once you have surpassed the experimentation stage and determined a need for a consistent flow of new feature data.
What is feature engineering
1. Functions
Functionally, there is nothing to differentiate data vs features - data points (link). Where feature engineering and data engineering really differ is in the objectives and motivations for constructing the pipelines. In general, data engineering serves a broader, more unified purpose than feature engineering. Data engineering platforms are constructed to be flexible and universal, ingesting various types and sources of data into a unified storage location where any number of transformations and use cases can be applied. The intent of a well constructed fact table or gold layer in a data lake is to provide a single source of truth that answers many different questions, produces many reports, and can be consumed by many downstream customers.
2. Practise
And in practice, an organization’s data engineering team will be responsible for the curation and maintenance of all data pipelines, not just those that relate to machine learning. These pipelines may power BI dashboards used by C-Suite, auditing reports that feed payroll, or event logs that show a user’s history of actions within the application.
Feature engineering, on the other hand, serves a specific purpose, finding the tailored inputs and columns that will generate the best predictive results for a machine learning model. Data scientists and machine learning engineers are not tasked with developing a universal data model that will ingest all data points throughout an organization, they just need to select, curate, and clean the data needed to power their models.
3. Machine learning
Now, as machine learning teams grow and begin to incorporate more and more data sources into their models, their feature engineering platform may start to resemble a larger data engineering platform in the tools and methodologies they employ. But, the intent is not to establish flexible data models that can be used throughout the organization - it is simply to power their machine learning models.
