u/jaivibi

Been building a small fleet lately and honestly the naming situation has gotten embarrassing fast, everything's just "the grey one" or "big cargo ship" at this point. Started thinking about proper naming systems and there seem to be a few directions people, go: mythology names, military-style alphanumeric codes, or straight descriptive function names like Scout or Runner. What I'm seeing a lot of right now is the faction-based lore approach, stuff like Aurora-class, or Vanta Wing, which looks great when you're posting build logs or displaying a whole fleet together. Retro-futurism vibes (think classic Blacktron or Futuron era aesthetics) seem to be having a real moment too, and that style lends itself well to punchy two-part names that are easy to remember and share. Do you stick to a consistent naming system across your whole fleet, or does each ship just get whatever feels right at the time? Keen to hear if anyone's landed on something that actually scales when you've got a dozen, ships to track, especially if you're building toward a cohesive display rather than just one-off MOCs.

Been thinking about this for a bit. Data centers are genuinely modular by nature, server racks, cooling units, cable runs, UPS systems, so it feels like it could translate pretty well into a LEGO build. The whole "build in blocks and scale it up" thing is basically how real data centers work now anyway. The skeptic in me wonders if it's just too visually flat to get traction on Ideas though. Like, it might nail the technical side but struggle to grab people who aren't already into that world. A cyberpunk-style data hub or a sci-fi server room might get the same builder satisfaction with way more shelf appeal. Has anyone seen a fan build that actually pulled this off well?

[ Removed by Reddit on account of violating the content policy. ]

Been wanting to make proper instructions for some of my custom builds and finally sat down to figure it out. Studio (the BrickLink one, not the old stud.io branding) seems to be the obvious starting point. The instruction maker in there lets you group steps, do page layouts, and export to PDF which is pretty solid. Worth knowing though, it's not automatic, you're still manually organizing every step yourself, so the learning curve is real. Took me a while just to get the step sequencing feeling natural. Biggest thing I've picked up so far is keeping each step small and obvious. If you're cramming too many pieces onto one page it becomes unreadable fast, especially for anything with tricky angles or internal structure. Separating submodels early also helps a lot, makes the whole build feel more logical when someone's following along. Also worth checking out Rebrickable if you want to see how other people have structured their MOC instructions before you commit to your own workflow. Gives you a decent sense of what readable pacing actually looks like in practice. Anyone here actually made their own instructions for a MOC? Keen to know if there's a workflow that makes the step prep less painful, or if it's just one of those things you have to grind through manually.

Something I keep running into with zero trust rollouts is the gap between what your IdP actually knows about and what's genuinely running in the environment. You can have Conditional Access configured pretty thoroughly in Entra, policies covering your known apps, MFA enforced, compliant device requirements in place, and then a user hits some internal, tool or contractor app that was never registered anywhere, never onboarded to SSO, and suddenly you're either blocking something business-critical or carving out an exception just to keep things moving. The core issue is that Conditional Access can only govern what's been integrated and targeted, so anything outside that scope is effectively invisible to your enforcement layer. The shadow IT side of this is messier than most ZT frameworks tend to acknowledge. Zero Trust as a model gives you the principles, but the actual enforcement depends on having app, discovery, registration, and continuous policy tuning in place first, and that inventory is rarely complete when you're mid-rollout. Discovery tooling helps close the gap but it's not instant, and it's only as good, as the telemetry sources feeding it, whether that's CASB, SSE, network logs, or proxy traffic. In the meantime you've got access requests hitting things you can't verify or apply policy to. The pattern I've been leaning toward lately is running in observe mode before touching enforcement. Use proxy-based visibility or your SSE layer to log what's actually hitting what, build the inventory from real traffic rather than, hoping someone documented things properly (they didn't), and then start onboarding apps in priority order based on what you're actually seeing. That way enforcement follows discovery instead of racing ahead of it. The harder part is usually the stakeholder conversation. Monitor-only isn't doing nothing, it's the step that keeps you from blocking a finance workflow at 9am on a Tuesday because you didn't know it existed. Framing it as building the foundation for least-privilege access rather than delaying enforcement tends to land better. Curious how others are handling the gap between discovery and enforcement, especially for legacy, apps where adding proper auth or IdP integration just isn't realistic in the near term. Are you using just-in-time exceptions with access reviews to manage those cases, or something else?

Been doing a discovery pass across our environment lately and the shadow IT problem is way messier than I expected. Defender for Cloud Apps keeps surfacing stuff nobody's heard of - random SaaS tools people signed up for with their work email, old internal apps that still auth, somehow (still trying to nail down whether that's legacy SSO, LDAP, or something else entirely), and things that clearly touch business data but have no owner listed anywhere. Worth noting that discovery fidelity varies depending on your licensing tier, so your mileage may vary on how complete the picture actually is. The inventory phase alone has taken way longer than planned and we're not even close to done. What I'm struggling with is the prioritization side once you actually have a list. My current thinking is to go hard on anything that's internet-exposed, touches sensitive data, has weak or, no auth, has external user access, or has no clear business owner - and triage the rest. Business criticality is probably worth stacking on top of that too, since some of these ownerless apps might still be load-bearing in ways that aren't obvious. I'd also check whether something can just be retired outright before spending time bringing it under SSO. I've seen arguments for blocking unknown apps outright and only bringing them back if someone complains, which feels aggressive but honestly might be realistic in some environments. The counter-risk is you block something with a hidden dependency and have a bad day. Keen to know how others are actually handling this - especially whether you're doing a full, inventory before any enforcement, or just starting with the highest-risk stuff and working outward from there.

Been thinking about this lately after a conversation with a colleague who's mid-rollout and genuinely frustrated. Their org had a cloud migration moving along nicely, then ZT got bolted on top of it, as a parallel workstream, and now both projects are fighting for the same people and the same decisions. App inventory's incomplete, device posture data is all over the place, and every new cloud onboarding is hitting a wall waiting for policy sign-off. The security intent is right but the execution is basically creating a bottleneck on stuff that was already moving. My take from what I've seen is that it usually comes down to scope and sequencing. If you start by trying to redesign the whole network and overhaul identity at the same time, yeah it's going to slow everything down. NIST's guidance on zero trust architecture has always framed this as an incremental approach, not a big-bang network redesign, and that tracks with what actually works in practice. Starting identity-centric, getting Conditional Access doing real work first, and scoping early phases to high-value apps and data tends to cause way less friction. The ZT work then starts to feel like it's enabling the migration rather than blocking it. The other thing that keeps coming up is that orgs treating ZT as a separate security, program rather than embedding it into the cloud migration itself are the ones hitting the worst bottlenecks. Duplicated approvals, resource contention, decisions that need two teams to agree before anything moves. That governance piece is where a lot of rollouts quietly stall right now. Curious whether others have hit this and what actually helped, especially in hybrid AD and Entra setups, where the on-prem side adds a whole extra layer of complexity around device trust and identity sync.

This keeps coming up in our environment and it's honestly one of the messier parts of any zero trust rollout. We've got service accounts in AD that predate everyone at the org, no owners listed, no documentation, and some of them are still actively authenticating to things. Disabling them feels risky without knowing what they touch, but leaving them sitting there with broad permissions is, obviously not great either, especially with how much attention supply chain and lateral movement attacks are getting right now. We've been trying to do a proper discovery pass before touching anything, but getting a clean picture across AD and Entra is more involved than I expected. The hybrid identity sprawl alone makes it hard to know what's actually in scope. We've been looking at whether something like a least-privilege scanner or CNAPP tooling could speed up the inventory side, but haven't fully committed to anything yet. Curious how others are actually handling the initial triage. Do you start by quarantining anything with no sign-in activity past a certain threshold, like 90 days, and work backwards from there? Or is there a smarter way to surface ownership without risking a prod breakage? We're also wondering whether it's worth pushing toward just-in-time access for anything we do keep, rather than leaving standing credentials in place long term.

Been working through a ZT rollout across a hybrid environment for a few months now and, the bit nobody really warns you about is how long the AD protocol hardening phase actually takes. Disabling NTLMv1 sounds simple until you start discovering how many old apps and service accounts silently depend on it. Same with enforcing LDAP signing - you flip that on and something breaks, and then you're, spending a week tracing it back to some line-of-business app that predates everyone at the org. Forrester data from earlier this year suggests around 45% of teams are hitting timelines, twice as long as they planned for, and honestly that tracks with what I'm seeing. The Entra side with Conditional Access and PIM is honestly the smoother part. It's the on-prem cleanup that drags. And the push toward passwordless and FIDO2 is actually making this worse in a way, because it, puts a spotlight on every legacy protocol still lurking in the estate that you'd maybe been quietly ignoring. The thing I keep running into is that most teams want to jump straight to the, cloud identity controls and treat the AD side as a problem to migrate away from eventually. But if you've still got DCs, forest trusts, and service accounts with hardcoded creds in the estate, those are your actual attack paths right now. We ran a BloodHound audit to map NTLM dependencies before touching anything else. Took longer than expected but it saved us from a lot of blind flipping of settings. Curious how others have handled the sequencing here - did you do protocol hardening first, or get the Entra control plane doing real work and circle back to AD later?

Been through a few of these implementations now and the question I get asked most is where to actually begin when you've got a messy hybrid setup. The answer I keep landing on is: Conditional Access first, before anything else. Get your Entra ID control plane doing real work - risk-based policies, MFA everywhere, device compliance signals from Hybrid Join. That layer gives you immediate wins and you can build on it without touching AD DS at all in the early stages. The trap I see people fall into is trying to fix Active Directory and cloud identity at, the same time, or worse, assuming they can just migrate away from AD and sidestep the problem. Legacy auth protocols, service accounts with hardcoded creds, complex trust relationships between forests - that stuff doesn't disappear because you've stood up Entra. If anything, ignoring it creates gaps that undermine everything you're doing in the cloud layer. Privileged groups in AD that sync up to Entra are a pretty obvious example. You can have perfect Conditional Access policies and still have an attacker walk straight through via an on-prem path you didn't account for. What's worked reasonably well for me is treating the hybrid integration as a signal unification problem first. Get Defender for Identity feeding risk signals into Identity Protection so on-prem activity actually influences your Conditional Access decisions in real time. Then layer in PIM for time-bound admin roles before you start the broader least-privilege cleanup in AD - that's usually where the scariest stuff lives anyway. Continuous Access Evaluation helps too once you've got Defender signals flowing, especially for unmanaged devices you can't fully control. Curious how others are sequencing this, especially if you've got multiple forests or a bunch of legacy apps that'll never support modern auth.

Work in IT security and I've been thinking about this for a while. There's heaps of space sets, nature sets, city stuff, but nothing that even comes close to representing what modern tech infrastructure actually looks like. A modular data center rack, maybe a server room with cable management chaos, or even just a little NOC setup with minifigs staring at screens. Feels like there's something there. LEGO Ideas has had a few data center and server room concepts pop up over, the years but none I've seen have hit the 10k supporter threshold needed for review. Makes sense I guess, minifig-scale server hardware is kind of abstract and doesn't have the same visual punch as a spaceship or a castle. Though honestly with the 18+ Icons line going absolutely wild right now I'd love to see someone make a serious push for it. The MOC side of things is where it gets interesting though. There's a site called domjant.hu that does instructions and brick lists for custom IT hardware builds, including things like an IBM Z16 and a Netflix Open Connect Appliance with functional opening doors. That's exactly the kind of detail that makes a build feel legit rather than just a grey rectangle. The IT Crowd display at Brickworld a few years back showed there's a real appetite for office and tech themed builds too. Curious if anyone here has actually tried something IT-related as a MOC. I've been tempted to do a server rack out of Technic pieces but would, love to see what others have pulled off before I commit to a parts order.

Went to pick up a Star Wars set a couple weekends ago and the shelves looked pretty rough at my local Target and Walmart. Not just a gap or two, more like whole sections thinned out. Checked a second store thinking it was just that location but it was similar there too. That said, I've seen some people posting recent hauls from Target with Ninjago and other, sets actually in stock, so it might be more regional or theme-dependent than a blanket thing. LEGO.com seems pretty active right now with promos and GWPs running, so at least, online isn't a dead end, though some stuff does seem to be store-exclusive or limited. Anyone else seeing this with Star Wars specifically? Wondering if it's just that theme getting picked over faster or if minifig-focused sections are holding up better. Curious what your local stores look like right now.

The one that comes up constantly is treating zero trust as a destination rather than a continuous posture. People get a vendor in, stand up ZTNA or SSE, tick the box, and then act like it's done. The whole point is that trust is evaluated dynamically on every access request based on context at that moment, not granted once and left alone. The moment you treat it as a solved problem you've basically rebuilt the perimeter with extra steps. The other one I see constantly in hybrid environments is assuming zero trust is mostly an identity problem. Identity is critical, no question, but if you've got unmanaged devices, service accounts with hardcoded creds, and lateral, movement paths that your IdP has never even heard of, identity controls alone aren't going to save you. Segmentation and protect surface definition matter just as much, probably more in environments where legacy infrastructure predates the current team. I've spent a fair bit of time cleaning up exactly this kind of thing on the AD, and Entra side of hybrid setups and it's always messier than the identity layer makes it look. The tool sprawl situation has gotten worse too as orgs consolidate vendors without actually rationalising the underlying architecture first. Curious what misconceptions others keep hitting, especially in orgs that are mid-implementation rather than greenfield. The gap between the framework on paper and what actually gets deployed seems pretty consistent across different environments regardless of where they started.

Picked up a dusty router at an op shop, chip markings are visible and it looks like a known Broadcom variant. Done a bit of reading and binwalk seems like the obvious first step to pull apart the firmware image and identify the filesystem, but I'm curious how people actually approach it when the firmware isn't publicly available and you have to dump it directly off the chip. Is UART usually the first thing you reach for, or do you go straight to chip-off depending on what's accessible? From what I can tell UART is generally preferred when the pads are exposed since it's non-destructive and you can sometimes grab, bootlogs or even a root shell, whereas SPI clip or chip-off is more of a last resort when nothing else is reachable. And once you've got the image, how messy does it actually get identifying the architecture? I've seen people say strings output and compiler hints usually get you most of the way there, and binwalk's architecture scan covers a lot of ground too. Broadcom stuff tends to be MIPS or ARM so maybe it's less of a guessing game than I'm expecting. Also curious whether anyone's been using Ghidra with any of the newer LLM-assisted plugins for the disassembly side of things, since that seems, to have picked up a lot of traction lately and would probably help when the strings aren't giving you much to work with.

Six CVEs in roughly six weeks, with CVSS scores hitting 9.9, is the kind, of pattern that makes you stop and rethink how you're actually ordering your PAM controls. The OpenClaw vulns are interesting because the root problem isn't any single patch gap, it's that the authorization, model around device pairing and agent execution scopes was never designed to handle the privilege boundaries you actually need. So you patch CVE-2026-32922, and three weeks later CVE-2026-44118 shows up abusing the MCP loopback in a slightly different way. Isolated fixes on a broken auth model just keeps producing new CVEs. What I keep coming back to is that most PAM frameworks were built around human admins doing deliberate things. An AI agent that can inherit standing permissions and move laterally at machine speed doesn't fit that model at all. The pairing scopes in OpenClaw are basically the new service account, low trust at creation, quietly accumulating access over time with no one auditing them. If you've got self-hosted instances running, the devices list enumeration to find stale pairing tokens seems like the obvious first triage step before anything else. For prioritization I'm landing on: scope minimization on agent identities first, runtime monitoring second (the ARMO eBPF approach, for flagging system.run shells is solid), and treating patch cadence as a distant third rather than the primary control. Curious whether others are finding OPA or similar policy-as-code approaches actually workable here, or whether that just moves the complexity problem somewhere else.

Been slowly putting together a collection of IT and tech-inspired Lego builds over the, past couple of years and finally got around to building a proper shelf for them. Mostly custom stuff - server racks, a little data centre vignette, some network gear MOCs. Nothing too elaborate but they look way better together than scattered around my desk. Went with a plywood shelf build in the end. Measured everything out first which honestly saved me from a few disasters - some, of these builds are awkward shapes and standard Kallax cubes just don't work for them. Added some LED strip lighting underneath each shelf level and it makes a huge difference. The server rack MOC in particular looks so much better with the lighting hitting it from below. Still figuring out dust protection without completely boxing everything in. Leaning toward acrylic panels on the front but haven't committed yet - I've seen some people doing wall-mounted cases with custom, printed backgrounds which looks great for themed collections, might be worth considering for the data centre section to give it some depth. Also been eyeing whether any of the newer smart brick stuff could add some subtle, lighting or sound effects to a couple of the builds without looking out of place. Feels like overkill but the idea is tempting. Anyone else gone the open shelf route and regretted it after a few months of dust buildup?

Something I keep running into doing M365 security work is orgs that have SPF and DKIM in place but, DMARC sitting at p=none, which basically means they're getting reports of spoofing attempts but doing nothing to block them. The monitor-only mode gives you visibility, sure, but if an attacker is spoofing support@yourcompany.com and hitting your employees, you're just watching it happen. This has gotten a lot more urgent lately - there's been a real surge in spoofed internal, email campaigns since mid-2025, with PhaaS tooling like Tycoon2FA making it easier to run these at scale. The lures are convincing too, HR notices, voicemail alerts, password reset prompts - headers give, them away if you know what to look for, but most users aren't checking headers. The jump to p=quarantine or p=reject is where a lot of orgs stall out, because they're scared of breaking legit mail flows, and honestly that fear isn't totally unfounded. The SPF 10-lookup limit is a real pain too. Once you've got Salesforce, Mailchimp, some third-party HR platform and a few others all included, you can quietly blow past that limit and suddenly SPF is failing on legitimate sends. I've seen this cause teams to roll DMARC back to monitoring mode because legit emails started bouncing and nobody could figure out why. SPF flattening or macros can help but they add complexity you have to actively maintain. The thing I reckon gets overlooked most is using subdomains for different email streams -, transactional, internal comms, marketing - so you can apply tighter policies without one misconfiguration nuking everything. It also makes enforcement rollouts way less stressful because you're not trying to audit every sending source at once. From a BEC angle the financial exposure is real and the numbers have only gone up. Spoofing-enabled impersonation of executives and finance teams is a significant chunk of that. The lookalike domain variants - swapping letters, adding hyphens - are harder to catch with just DMARC since they're technically different domains. That's where you need something watching for newly registered lookalikes, and BIMI is worth looking at, too if you want to give users a visual signal that a sender is actually authenticated. Defender

Been thinking about this lately because I started replaying LEGO Star Wars: The Skywalker Saga and it got me curious. I genuinely reckon LEGO games were the reason a lot of people got into gaming properly, not just as a casual thing. The puzzles, the exploration, the light platforming - it's a pretty natural bridge to bigger open-world stuff. For me personally it went LEGO games to Zelda, which makes sense in hindsight. The puzzle-solving and dungeon-style exploration in LEGO City Undercover especially felt weirdly similar to what I ended up doing in Ocarina of Time. Same kind of loop - find a tool, enable a new area, figure out what the game is actually asking you to do. And LEGO Worlds scratching that Minecraft itch before I ever actually touched Minecraft was funny to realise in retrospect. Curious if others had a similar path. Like did a specific LEGO title push you toward a whole genre you wouldn't have, tried otherwise, or do you think they're more of a standalone thing that doesn't really translate?

Been thinking about this a lot since the OpenClaw CVE started doing the rounds. The sandbox bypass via heartbeat context inheritance is nasty on its own, but what it really, exposed for me is how unprepared most PAM setups are for AI agents operating in hybrid environments. We're running Entra ID with a mix of on-prem AD and cloud workloads, and the uncomfortable truth is that most of, our PAM policies were designed around human admins, not autonomous agents that can inherit standing permissions and move laterally at machine speed. The stuff I'm actively working through right now: getting JIT access scoped properly for agent identities so there's no standing privilege to, steal in the first place, and trying to get Defender XDR hunting on unusual tool usage patterns rather than just flagging known-bad signatures. The authenticated delegation angle is interesting too, linking each agent action back to a human creator rather than letting agents impersonate accounts outright. Easier said than done when your dev team has self-hosted runners sitting on developer laptops with broad credential access. Curious how others are scoping this in practice, especially in Microsoft-heavy hybrid setups. Are you treating agent identities as their own workload identity tier in Entra, or just bolting controls onto existing service account policies and hoping for the best?

[ Removed by Reddit on account of violating the content policy. ]