Beyond Coding: A Cybersecurity Microcredential Built with Teachers

Every teacher started with an introduction to cybersecurity and the CIA triad: keep information confidential, keep it correct (integrity), and keep it available to the people who need it. One unplugged activity, meaning no computer required, used the Caesar cipher, a code more than 2,000 years old: shift every letter forward by the same number, the key. Type a message and move the key. Then switch to Break a secret and try to read a message without knowing the key. Teachers used the activity to connect cybersecurity to the arithmetic their students already practice.

Number the alphabet from A = 0 to Z = 25. Encoding adds the key to each letter’s number, and anything past 25 wraps around to the start, the same “clock arithmetic” that turns 14:00 into 2 p.m. Decoding subtracts the key. The cipher protects confidentiality, the first letter of the CIA triad, but only a little: just 25 keys are worth trying, so Try every key breaks any message in seconds. Teachers used the activity to practice addition and subtraction with students while teaching the history of codes.

Encryption is E(x) = (x + k) mod 26 and decryption D(y) = (y − k) mod 26, with a key space of 26 (25 nontrivial keys). Try every key runs that exhaustive search, then ranks each candidate by Pearson’s χ² distance between its letter counts and typical English frequencies, the first step of frequency analysis. The ASEE paper pairs this unplugged activity with a plugged one, a live cyber threat map that students could track day to day. The demo is the page’s illustration of the activity; the paper describes its purpose, not its procedure.

The microcredential is the context here, and the study is the subject: the activity appears because it shows the kind of resource teachers later asked for most, an unplugged, ready-to-use task with a clear link to their own subject (here, arithmetic and history). The ASEE paper reports that sample lesson plans and unplugged activities were what teachers found most helpful, and that computational thinking materials helped them connect cybersecurity to mathematics and geography. The candidate ranking is the page’s own addition.

Each pilot ran longer and offered more than the one before: four weeks and two modules, then six weeks and five modules, then seven weeks and 12. Pick a pilot to see what it offered; “changed” marks what the team revised after hearing from the previous group. From Pilot 2 on, every teacher took the introduction and then chose two more modules, so the course could fit a math teacher, a science teacher, or a literacy teacher. Tap modules to build a pathway of your own.

After Pilot 1, the team listened to what five teachers said, thought, did, and felt during the course, then redesigned it for Pilot 2 with more relevant content and more support for connecting cybersecurity to each teacher’s subject. Pilot 2 added sample lesson plans and flashcards; Pilot 3 added videos and design thinking flashcards, and moved office hours to “by request.” In Pilot 3, choosing two of 11 modules gives 55 possible pathways. Abstraction, hiding details a learner does not need yet, drew 29% of all picks; minimization drew 2%.

Table 2 tracks the design across pilots: module count, requirements, office hours, resources, and instruments. The content knowledge questionnaire and attitude survey begin with Pilot 2, and focus groups, interviews, and biweekly progress reports run throughout. The new modules in Pilots 2 and 3 are classic secure-design principles (data hiding, least privilege, layering, domain separation, process isolation), taught as ideas that apply well beyond programming, which is the “beyond coding” of the title.

The design follows a teacher-as-partner cycle: prototype, test with a cohort, gather feedback through progress reports, focus groups, and interviews, then revise. The ASEE paper names the stages (empathize, define, ideate, prototype, test, implement) and Loucks-Horsley’s principles of effective STEM professional development; the journal frames the same cycle as systems thinking around three design factors (a user-friendly platform, content-rich resources, and mastery-based, competency-centered pedagogy). The pilots differ in length, content, and instruments at once, so differences between cohorts cannot be attributed to any one change, a limitation the authors state.

The 30 teachers chose to take part. Most were women (73%), most had taught for 16 years or more, and most had taught computer science for three years or less. They taught mathematics, science, computer science, and literacy, from prekindergarten to high school. Pick a characteristic and tap a row to light up that many teachers. Time in the course varied widely: teachers reported between six and 40 hours.

Each dot is one teacher. Teachers could list more than one subject and more than one grade band, so those shares add to more than 100%. Nearly two thirds (63%) had already taken a cybersecurity class, yet 88% of those who reported computer science teaching experience had three years or less of it. Time is harder to measure than it looks: the course website logged between two and 192 hours per teacher, while teachers’ own reports ran from six to 40 hours.

Time was measured two ways: learning management system logs (2 to 192 hours, average about 40) and self-reports in biweekly progress reports (6 to 40 hours, average about 14). The authors removed the 192-hour value as a likely open browser session before correlating time with teacher characteristics. They report a weak positive relationship between time in the resources and teaching literacy or high school, a weaker one in the other direction for female and STEM teachers, and less time for computer science teachers with prior programming experience; no coefficients are printed.

At the undergraduate level and above, each row shows the whole count of teachers that its printed share implies. Every share in Table 1 matches exactly one count except “16 or more years” of teaching at 59%, which no count out of 30 produces; the other four bands account for 12 teachers, which leaves 18 (60%). Logged and reported hours differ by a factor of about three on average, so RQ2’s answer depends on the instrument; both measures, and the correlation analysis, would need the per-teacher data to reproduce, which the authors hold under IRB restrictions.

The journal paper reports two survey statements. Before the course, 15 of 22 teachers agreed that “I can effectively teach all students computer science”; afterward, 12 of 14 did. The ASEE paper asked about concern instead. Over the first two pilots, fewer teachers said they were concerned about improving how they teach computer science, falling from 75% to 45%. Pick an item to compare the before and after groups.

Self-efficacy is how capable a person believes they are; teachers with more of it are more likely to try new material with students. Each square is one teacher who answered; filled squares agreed. The groups are small, and not everyone answered both times: 22 teachers answered before and 14 after. The concern items move in the other direction, which reads as good news here, because fewer teachers worried about how to teach computer science.

Both journal items moved from 68% to 86% agreement on the self-efficacy subscale. The ASEE concerns items, from the same Ravitz et al. (2017) instrument, were given three times; item 8 moved from 75% to 77% to 45%, and item 9 from 75% to 44% to 36%. The authors connect the rise in confidence to the Dunning-Kruger effect, the tendency of beginners to rate their skill above their measured skill, and argue that teachers need continuing support rather than a one-time course.

The papers report shares without tests. At these sample sizes, the page’s 95% Wilson intervals for items 11 and 12 (47% to 84% before, 60% to 96% after) overlap, and Fisher’s exact test on the two administrations gives a two-sided p ≈ 0.43. Both treat the administrations as independent samples, while most of the same teachers answered both, and responses were not linked. Read together with the interviews, the counts support the authors’ description of increased confidence; they do not by themselves establish it.

• The share of teachers who felt they could teach computer science to all students rose from about two thirds to almost nine in 10.
• Fewer teachers felt concerned about improving how they teach computer science after the first two pilots.
• Teachers valued working at their own pace and getting to know the other teachers and the course team.
• They asked for ready-to-use lesson plans, more videos and fewer long readings, examples for their grade levels, and more help connecting cybersecurity to their own subjects.
• At least 14 of the 30 teachers later used lesson plans they had created in the course.

• Agreement with “I can effectively teach all students computer science” rose from 15 of 22 teachers to 12 of 14.
• On the ASEE concerns survey, agreement with “I am concerned about improving how I teach CS” fell from 75% to 45%.
• Time varied widely: two to 192 logged hours, six to 40 reported hours.
• Interviews with 19 teachers produced two themes: resources (what the course offered and what teachers used) and implementation (in their classrooms and in the next version of the course).
• An informal follow-up found at least 14 of 30 teachers using lesson plans they had built.

• Self-efficacy rose. Items 11 and 12 moved from 68% agreement (15 of 22) to 86% (12 of 14), across Cohorts 2 and 3.
• Concern fell. On the ASEE concerns survey across Pilots 1 and 2, item 8 moved from 75% to 77% to 45%, and item 9 from 75% to 44% to 36%.
• Time varied widely. Logged time ran 2 to 192 hours (about 40 on average) and reported time 6 to 40 hours (about 14).
• Teachers shaped the design. Resource themes (flexibility, community, office hours, videos, lesson plans, flashcards) and implementation themes (ready-to-use materials, unplugged activities, background knowledge, grade-band examples, demonstrations) drove each revision.
• Some work reached classrooms. At least 46% (14 of 30) later reported using lesson plans they had created, by informal follow-up email.
• Five recommendations. Match the course to teachers’ backgrounds and curricula and design for motivation; build minimal-modification resources at novice, intermediate, and advanced levels; include unplugged and plugged activities with shorter readings and videos; name disciplinary connections inside and beyond STEM; and offer synchronous implementation support beyond email.

Cybersecurity touches every subject that uses information, which is every subject. Teachers cannot bring it to students without time, materials, and support that fit their own classrooms. This study shows one way to build that support: start small, listen to the teachers who take the course, and rebuild it with them. Ultimately, the teachers’ own requests (ready-to-use lessons, short videos, examples for their grade level) became the course’s design.

Microcredentials spread quickly during the pandemic, and little research describes how to design one for teachers, especially in cybersecurity. This paper contributes a documented, three-iteration design with teacher feedback at each step, and a set of concrete recommendations that other designers can test. It also makes a case for teaching secure-design principles as ideas (abstraction, least privilege, layering) that any teacher can connect to their subject.

The study models a partnership-driven, design-based approach to professional learning in a field where most teachers start as novices. Its strongest evidence is qualitative and design-oriented: what teachers used, what they asked for, and how the course changed in response. The quantitative results are descriptive, from small, partly overlapping groups, and the authors’ own future work (a corroborating study of the final design, tailoring by teacher background) is where effect estimates belong.

Notes from building this page

• Survey sample sizes. The Methods report Cohort 2 at 16 of 16 before and 11 of 16 after, and Cohort 3 at seven of nine and five of nine, which sum to 23 and 16; Figures 1 and 2 report 22 and 14.
• Identical items. Items 11 and 12 report the same counts (15 of 22, then 12 of 14), and Figure 2’s caption omits “computer science” from the item the text quotes. One of the two figures may repeat the other.
• Scale. The journal describes the 29-item subscale as 0 (strongly disagree) to 5 (strongly agree); the ASEE paper describes the same instrument as a 1 to 5 Likert scale.
• Pilot 1 surveys. Table 2 marks no attitude survey in Pilot 1, while the ASEE Methods give the survey before Pilot 1, after Pilot 1, and after Pilot 2. The ASEE pre-survey n of 16 matches Pilot 2’s enrollment, not Pilot 1’s five teachers, so “pre” may refer to the start of Pilot 2.
• Item 8 sample sizes. No count of 11 teachers prints as 77%, and no count of nine prints as 45%. With the two later sizes in item 9’s order (post n = 9, post-post n = 11), 45% is five of 11 and 77% is seven of nine (77.8%) truncated. Item 9’s printed shares all match whole counts.
• Module choice rule. The text describes choosing between Modules 2 and 3, then 4 and 5, then within Modules 6 to 12 (Pilot 3 numbers its modules 0 to 11); Table 2 lists “Module 0 + Choose 2” for Pilots 2 and 3. Figure 4’s 48 selections fit two choices each by 24 of the 25 teachers in those pilots, so the page’s pathway builder follows Table 2.
• Rounding. Table 1 rounds to the nearest percent (eight of 30 prints as 27%), yet its “16 or more years” share of 59% matches no whole count; 18 teachers would print as 60%. The follow-up figure “at least 46% (14 of 30)” is 46.7%, which the same rounding prints as 47%.
• The page’s statistics. Wilson intervals and Fisher’s exact test (two-sided p ≈ 0.43; one-sided 0.22) treat the before and after groups as independent, which overstates the information in partly overlapping, unlinked responses. They appear only to show how much these sample sizes can support; the paper makes no inferential claim.
• Byline. The published records list Andrea C. Borowczak as Andrea C. Burrows; this page uses the name she prefers.

Try this in class

1. Pick a key from 1 to 25 and encode a short sentence by hand, writing each letter’s number, adding the key, and wrapping past 25. Swap messages with a partner, but keep the key secret.
2. Break your partner’s message by trying keys one at a time, then check your answer with Break a secret above. Count how many keys you needed.
3. Write two sentences on which part of the CIA triad the cipher protects, and why a code with only 25 keys protects it poorly. Suggest one change that would give a code breaker many more keys to try.