Thomas Sowell once wrote:
“There have always been ignorant people, but they haven’t always had college degrees to make them unaware of their ignorance. Some people imagine that they are well informed because they have memorized a whole galaxy of trendy dogmas and fashionable attitudes.1”
I do not quote that comfortably.
I teach at a college. I assign grades. I participate in the very system Sowell is critiquing. If credentials can create the illusion of arrival, I help distribute those credentials.
What makes the quotation linger for me is not cynicism about education, but memory.
I began my career in IT long before “cybersecurity” became the polished term it is today. In those early years, the work was simply part of keeping systems operational—managing access, responding to anomalies, hardening configurations, protecting data. Over time, those responsibilities sharpened and formalized. What had once been folded into general IT operations gradually evolved into a defined discipline with its own vocabulary, standards, and compliance structures.
The field was maturing while I was inside it. Years later, I earned my first degree. And when it came, it opened doors that experience alone had not. Titles changed. Opportunities expanded. Conversations shifted.
The credential mattered. But it did not replace the apprenticeship that had already formed me.
During two decades as a defense contractor—through IT’s evolution into what we now call cybersecurity—I watched the regulatory landscape mature alongside the technical one. What began as DFARS 252.204-7012 pressed contractors toward safeguarding requirements derived from broader NIST guidance. That matured into NIST SP 800-171, clarifying expectations for nonfederal systems handling Controlled Unclassified Information. Now we operate within the expanding orbit of CMMC, formalizing assessment and accountability across the defense industrial base.
From a distance, these appear to be documents and models. Up close, they represent a system learning under stress.
Breaches forced clarity. Self-attestation proved thin. Verification followed. Consultants and assessors emerged. Vendors articulated why compliance was necessary and how they could assist. An ecosystem formed around risk management and accountability.
Anyone can read a control requirement.
That statement feels almost trivial. A control in NIST SP 800-171 is written in clear language. Limit access. Log events. Protect data. Establish procedures. It is possible to read it, map it, and even evaluate its stated presence without ever having configured the systems it governs.
Over the years, I have observed assessors—well-intentioned, credentialed professionals—who could quote the control but struggled to explain its technical foundation. When asked to describe what it meant operationally, or how it interacted with architecture in practice, the answers sometimes hovered at the surface. The language was correct. The depth was uncertain.
I do not exempt myself from that dynamic. There have been controls I initially struggled to understand in their deeper meaning. At times, the language in NIST SP 800-171 seems to gesture backward toward its origins in NIST SP 800-53. Without familiarity with that broader context—the risk management philosophy, the federal system assumptions, the historical evolution of control families—certain requirements can feel compressed, almost elliptical. They make sense grammatically, but not fully architecturally.
Understanding sometimes requires tracing the lineage of the language itself. Depth takes time, and context is rarely supplied in footnotes.
Behind every line sits history—compromised credentials, lateral movement, insider misuse, audit failures, and governance breakdowns. A logging requirement is not merely about enabling logs. It implicates storage architecture, monitoring processes, analyst fatigue, retention policies, and cost constraints. A multifactor authentication mandate reshapes user behavior and operational tempo.
Controls are compressed lessons written in the aftermath of failure.
I have always been skeptical of neat solutions—perhaps a generational habit. Even early in my career, I was wary of the idea that documentation equaled security. Experience did not shatter that skepticism; it reinforced it. I watched well-written policies coexist with weak implementation. I saw beautifully mapped controls collide with legacy infrastructure and limited resources. I observed checklists completed while risk remained stubbornly present.
Documentation matters. Mapping matters. But they are beginnings, not endings.
This is where credentials can mislead.
A degree or a certification is not a guarantee of proficiency. It does not certify wisdom. It does not promise competence under pressure. It indicates that a student obtained enough information—and demonstrated sufficient understanding—to meet a defined standard at a particular moment in time.
Proficiency comes with practice.
It comes with repetition, correction, frustration, and refinement. It comes when knowledge is applied in environments that resist simplicity.
Now I teach at a community college, and my approach reflects that history. I emphasize hands-on engagement. I want students using the tools, parsing logs, configuring systems, breaking and fixing environments. Theory matters, but theory without contact with real interfaces remains abstract.
My students are intelligent and motivated. What they lack is not capacity but time. They have not yet watched systems age. They have not seen how small decisions accumulate into structural fragility. They have not experienced the slow erosion of institutional memory.
Recently, in my Penetration Testing class, we were discussing persistence. Attackers look for footholds that survive updates, survive audits, survive personnel turnover. Persistence is not merely technical; it is temporal.
To explain this, I turned to the Voyager probes.
Launched in 1977, Voyager 1 and Voyager 2 were designed for missions measured in years. They continue transmitting data from interstellar space. The engineers who designed their systems have largely retired. Some are gone. The technology onboard is primitive by modern standards. A message sent from Earth takes many hours to arrive. A reply takes just as long.
And yet we still communicate.
That persistence depends not only on hardware but on knowledge handed down. Documentation preserved. Expertise transferred. Without continuity, those spacecraft would be silent artifacts drifting in darkness.
When I look at legacy systems in cybersecurity, I sometimes think of Voyager. We are still speaking to technology built under assumptions that no one clearly remembers. Decisions made decades ago constrain today’s architecture. Documentation is incomplete. Original architects are unavailable.
The system persists. So do its vulnerabilities.
Anyone can read a control requirement.
Fewer can understand how that requirement interacts with a decades-old environment whose designers are no longer present to explain their trade-offs. Fewer still can implement it without destabilizing something else.
Education provides information. With discipline, information becomes knowledge—an integrated understanding of how components relate. Wisdom forms more slowly. It appears when knowledge is tested under responsibility and refined through consequence.
I cannot compress decades of earned experience into a semester. I sometimes wonder whether I am granting confidence faster than competence. But I can train students to see beneath the surface. I can show them that frameworks evolve in response to failure. I can require them to think in systems rather than in checklists.
And perhaps, in a quieter way, I can encourage something like an Aurelian posture toward their work.
Marcus Aurelius governed an empire he could not fully control. Most of us govern smaller domains—networks, systems, programs—but the discipline required is not so different. Requirements change. Budgets constrain. Personnel rotate. Documentation decays. Threats evolve. Much of this lies beyond our control.
What remains within our control is rigor. Documentation. Integrity in assessment. Patience in diagnosis. Calm in incident response. The refusal to confuse certification with competence. The refusal to let ego outrun experience.
In cybersecurity, as in governance, the work is rarely dramatic. It is patient. Repetitive. Often invisible. It demands steadiness more than brilliance.
My degree opened doors that experience alone did not. For that, I am grateful. But experience gave depth to what the degree formalized. One without the other would have been incomplete.
Perhaps the classroom is less a summit than a launch point—more mission preparation than destination. The real trajectory unfolds slowly, shaped by repetition, responsibility, and time.
And if we do our work well, the systems our students inherit—and the knowledge they carry forward—will continue speaking long after the certificates on their walls have faded into background decoration.
One thought on “Credentialed and Unprepared: Systems, Persistence, and the Slow Education of a Practitioner”