01 / Infrastructure & security
Making secure infrastructure work in practice.
Connecting identity, endpoints, enterprise systems, and compliance readiness in a defense environment—where a technical decision has to support both protection and the people doing the work.
- Context
- Airborne Systems / Defense
- Contribution
- IT Systems Engineer · Contract
- Project type
- Engineering case study
The challenge
Connect security requirements to everyday operations.
My focus
Infrastructure, identity, endpoints, and readiness.
The lens
Make the controls understandable and operable.
01 / The problem
A secure system still has to be a usable system.
Enterprise infrastructure is a set of dependencies. A person needs an identity, a suitable device, the right permissions, and a reliable path to the application or information they need. A decision made in any one of those layers affects the others. Treating each layer as a separate tool problem can leave gaps between what a policy intends and what the environment actually permits.
In a defense setting, that engineering challenge also involves sensitive information and demanding security obligations. My work at Airborne Systems connected infrastructure and compliance engineering, including technical strategy for CMMC Level 2 readiness. The practical question is how to turn requirements into clear technical priorities while keeping the environment useful to the business.
Access has context
A valid account alone does not explain whether a particular action or resource is appropriate.
Changes have dependencies
A configuration change can affect sign-in, application availability, and the people who support them.
Readiness needs evidence
A written control and an operating control need a traceable connection.
02 / My contribution
Working across the boundaries between systems.
From February 2025 to May 2026, I worked as a contract IT Systems Engineer at Airborne Systems, connecting infrastructure and compliance engineering. My focus spanned enterprise environments, network architecture, identity and authentication, endpoint security, and translating security requirements into technical work. That breadth was useful because an issue rarely respects the boundary between a team, a product, and a policy.
The models below explain my approach at a high level: the questions I use to connect a requirement to an operational decision.
Understand the environment
Start with the work people need to accomplish and the systems, identities, and dependencies that support it.
Translate the requirement
Connect a security objective to the layer where it can be enforced, maintained, and explained.
Keep the operational view
Consider access, support, change, and evidence together so the solution remains practical after implementation.
03 / How it works
One environment. Three engineering questions.
Explore how access, change, and evidence connect. Select a view, then a stage to inspect the reasoning behind it.
Identity → Context → Resource
What needs to be true before access is allowed?
Start with the person and purpose, then connect device context and permission to the resource.
Identity
The starting point is a known identity and an understood business purpose. Authentication and authorization answer different questions: proving who is asking does not by itself establish what that identity should be allowed to do.
Conceptual models of access, change, and evidence. Employer-specific systems are represented only at the level of general engineering principles.
Read all model notes
Access path
- Identity — The starting point is a known identity and an understood business purpose. Authentication and authorization answer different questions: proving who is asking does not by itself establish what that identity should be allowed to do.
- Device context — Access decisions interact with the state of the endpoint and the way it connects. Thinking across identity and endpoint security helps avoid assuming that network location alone establishes trust, a principle described in NIST’s zero trust architecture guidance.
- Permission — The useful unit of access is the work that needs to happen. An engineering review asks which resource and action are required, how that permission is granted, and how it changes when the person’s responsibilities change.
- Resource — The path should end in a decision that can be understood and investigated. This is where policy, the application or data, and operational visibility meet. A diagram is only useful if the team can explain how the real environment behaves.
Change path
- Map the dependency — Before choosing a technical action, I want to understand the dependency it touches. A sign-in change, for example, can affect the user experience and application access as well as security.
- Define a check — A change is easier to reason about when success has a concrete meaning. The check should cover the intended security behavior and the work that must continue. That makes the tradeoff discussable before a technical choice becomes an operational assumption.
- Plan the transition — Resilience includes the ability to respond when an assumption turns out to be wrong. My approach is to consider how a change would be supported and adjusted, and who needs the context to act when the environment behaves differently than expected.
Evidence path
- Requirement — The first question is what the requirement is intended to protect. Scope matters: a broad policy statement needs to be connected to the relevant systems, information, and people before it becomes a useful implementation task.
- Technical control — A control needs an operating expression. Depending on the requirement, that may involve identity, authentication, endpoint settings, network boundaries, or a managed process. The engineering work is to connect those decisions coherently.
- Evidence & review — Evidence should help someone understand what is in place and what needs attention. Readiness is an ongoing engineering concern as systems and responsibilities change.
Choose a perspective, then select a stage. Keyboard: arrow keys switch perspectives.
04 / Key decisions
The choices behind the solution.
Start with the dependency, then the tool.
Why it mattersThe right configuration depends on the workflow and the systems around it.
The tradeoffContext gathering takes time, but makes the technical decision easier to defend and support.
Consider security and usability in the same review.
Why it mattersA control has to fit the people and operations it protects.
The tradeoffConvenience cannot decide the security requirement; the design must work within the real constraints.
Treat evidence as part of the design.
Why it mattersA control is easier to maintain when its purpose and behavior are traceable.
The tradeoffDocumentation needs ongoing ownership as the environment changes.
05 / What it produced
A connected engineering perspective.
This case presents the scope of my work at Airborne Systems and the reasoning that connected its parts. The through-line was translating between infrastructure detail, security expectations, and the organization’s practical needs.
The public output is an explanation of that engineering approach. It intentionally describes the work at the level of responsibilities and decisions, without publishing internal architecture or claiming a measured performance improvement.
Infrastructure context
A view of how enterprise systems, identities, and endpoints depend on one another.
Readiness perspective
A way to connect a security requirement, its implementation, and supporting evidence.
Operational reasoning
An approach to change that includes validation, support, and adaptation.
Resilience is also a way of working.
Moving across industries has taught me to build context quickly, ask where a dependency really sits, and revise the approach as I learn. That habit helps me connect technical depth with the communication needed to move a complex problem forward.
Project context & references
Feb 2025–May 2026 · Engineering case study
Next / SCE Strategic Dashboard