At my prior company we had a database that used EAV for most things, and we had column names like Col1, Col2, Col3... dates and times were split, and there were flags galore... Joe would probably faint if he saw it 😉
But unfortunately that was the schema... it came to us prepackaged from the vendor, and changing it would have meant changing literally hundreds of other objects in SQL, would have meant changing application code for multiple systems, and would have probably taken hundreds of hours to complete and test and deploy...
And so we just had to deal with it. The company wasn't going to invest that kind of time and money into fixing something that worked - and worked pretty well - just because there was non-standard SQL in the system. We couldn't just tell management "Sorry, we could easily do what you want done - and it'd be perfectly fine - but first we're going to insist you spend the next six months fixing a problem that is only technically a problem from a standards perspective... no, it works fine, it's more about the principle you see... wait, why are you calling for security?"
Truth be told over the years I've worked with dozens of enterprise systems and every single one of them had schema that weren't standard. That is the reality of the business.
It'd be one thing to give the OP a possible solution and them tell them oh by the way you really shouldn't design a table like that... but telling someone they're screwed because their schema doesn't meet the standard and acting like there is no other recourse but to scrap and redesign... that's not being helpful, that's being pedantic and rude.